---
title: Connection Pooling
description: Menggunakan ulang koneksi database agar tidak membuka koneksi baru di setiap request. Kunci aplikasi yang sibuk.
canonical: https://penasihathosting.com/wikihosting/connection-pooling
type: wiki
locale: id
updated: 2026-10-29
author: Willya Randika
---

# Connection Pooling

## Overview

- **Summary:** Menggunakan ulang koneksi database agar tidak membuka koneksi baru di setiap request. Kunci aplikasi yang sibuk.
- **Author:** Willya Randika ([profile](/penulis/willya-randika))

## Article

Connection pooling menyimpan sekumpulan koneksi database yang sudah terbuka dan meminjamkannya ke request lain. Tanpa pool, setiap request membuka koneksi baru, melakukan handshake, lalu menutupnya. Biaya itu kecil saat sepi, tapi menjadi mahal saat ratusan request datang bersamaan.

## Kenapa koneksi mahal

MySQL, MariaDB, dan PostgreSQL membatasi jumlah koneksi. Setiap koneksi memakai memori dan proses atau thread. Kalau aplikasi membuka koneksi lebih cepat daripada database menutupnya, request akan gagal dengan error seperti “too many connections” atau “remaining connection slots are reserved”.

Gejalanya sering muncul sebagai [Error 500](/wikihosting/error-500) atau [Error 503](/wikihosting/error-503) saat trafik naik. Menaikkan `max_connections` tanpa menambah RAM hanya memindahkan masalah.

## Cara kerja pool

Aplikasi meminta koneksi dari pool. Kalau ada koneksi idle, koneksi itu dipakai ulang. Kalau pool penuh, request menunggu sampai ada yang dikembalikan atau timeout. Setelah selesai, koneksi dikembalikan ke pool, bukan ditutup.

Ukuran pool tidak harus besar. Mulai dari 5 sampai 20 koneksi per aplikasi, ukur waktu tunggu dan penggunaan database, lalu sesuaikan. Rumus kasar `pool_size = core_count * 2 + effective_spindle_count` bisa jadi titik awal, tapi beban nyata lebih penting.

## Konfigurasi

PgBouncer untuk PostgreSQL bisa memakai mode `transaction` agar efisien. Namun fitur yang bergantung pada session, seperti beberapa prepared statement, `SET`, atau advisory lock, bisa bermasalah. Uji dengan driver yang Anda pakai.

Di Prisma, atur `connection_limit` pada URL, misalnya `?connection_limit=10&pool_timeout=20`. Untuk serverless, gunakan pooler karena setiap invocation bisa membuka koneksi baru.

Di MySQL, pantau `SHOW STATUS LIKE 'Threads_connected';` dan `SHOW VARIABLES LIKE 'max_connections';`. Di PHP-FPM, setiap worker bisa memegang satu koneksi. Lima puluh worker dengan pool sepuluh bisa berarti ratusan koneksi kalau tidak dibatasi.

## Yang sering salah

Pool yang terlalu besar meningkatkan contention dan memori database. Koneksi yang tidak ditutup di blok finally akan bocor sampai pool habis. Pool juga tidak memperbaiki query lambat. Query tanpa index tetap lambat.

Jangan mengandalkan session state di koneksi yang dipakai bersama. Variabel session bisa tercampur antar request.

Connection pooling melengkapi [Redis](/wikihosting/redis) untuk cache dan [PHP-FPM](/wikihosting/php-fpm) untuk worker. Kalau query lambat, mulai dari [Index MySQL](/wikihosting/mysql-index).

## FAQ

<Accordion>
  <AccordionItem title="Apakah shared hosting memakai connection pooling?">
    Biasanya provider mengelola database secara terpusat, tapi akun Anda tetap punya batas koneksi. Aplikasi yang membuka koneksi berlebihan bisa kena limit.
  </AccordionItem>
  <AccordionItem title="Apakah PgBouncer selalu cocok?">
    Tidak. Mode transaction bisa memutus fitur yang bergantung pada session. Uji prepared statement, advisory lock, dan transaksi aplikasi Anda.
  </AccordionItem>
  <AccordionItem title="Berapa ukuran pool yang ideal?">
    Tidak ada angka universal. Mulai kecil, ukur latency dan waktu tunggu, lalu naikkan sampai database menjadi bottleneck.
  </AccordionItem>
</Accordion>