PHP-FPM Penuh Bukan Berarti Server Kurang Kuat: Cara Membaca Antrean Request

Ketika website PHP mulai lambat, dugaan pertama biasanya mengarah ke hosting yang kurang kuat. Padahal, cukup sering masalahnya lebih spesifik: semua worker PHP-FPM sedang sibuk, sementara request baru harus menunggu giliran.

PHP-FPM atau PHP FastCGI Process Manager adalah pengelola proses yang menjalankan aplikasi PHP di belakang web server seperti Nginx. Bayangkan PHP-FPM sebagai loket pelayanan. pm.max_children menentukan berapa banyak loket yang boleh bekerja bersamaan. Jika semua loket terisi, pengunjung berikutnya masuk ke antrean.

PHP-FPM memang dirancang untuk situs dengan beban tinggi dan menyediakan pengaturan proses, status, serta slowlog untuk membantu diagnosis. ([php.net](https://www.php.net/manual/en/install.fpm.php/install.php?utm_source=openai))

Gejala website lambat karena antrean PHP-FPM

Masalah ini biasanya muncul dengan pola yang agak membingungkan. Halaman statis seperti gambar atau file CSS tetap cepat, tetapi halaman yang membutuhkan PHP terasa berat. Pada jam sibuk, waktu tunggu meningkat, lalu sebagian request berakhir dengan error gateway timeout.

CPU server belum tentu 100 persen. Bahkan, server bisa terlihat cukup santai karena hambatannya bukan kekurangan tenaga komputasi, melainkan jumlah worker yang tersedia. Jika satu request memakan waktu lima detik dan semua worker sedang menjalankan proses serupa, request baru tetap harus menunggu meski CPU belum penuh.

Beberapa tanda yang patut diperiksa:

• Nilai listen queue sering lebih besar dari nol.
• max children reached menunjukkan bahwa batas proses pernah tercapai.
• Jumlah proses aktif terus mendekati pm.max_children.
• Log aplikasi atau PHP-FPM mencatat banyak request lambat.
• Nginx sesekali mengembalikan 504 Gateway Timeout.

Jangan langsung menaikkan pm.max_children

pm.max_children bukan angka yang semakin besar semakin baik. Setiap proses PHP membutuhkan memori. Jika nilainya dinaikkan tanpa menghitung RAM yang tersedia, server dapat mengalami tekanan memori, mulai memakai swap, atau bahkan mematikan proses secara paksa.

Perkiraan awal yang sederhana adalah membagi memori yang realistis untuk PHP dengan rata-rata penggunaan memori satu proses PHP:

pm.max_children = memori untuk PHP / rata-rata RAM per proses PHP

Misalnya, jika tersedia sekitar 1.200 MB untuk PHP dan satu worker rata-rata menggunakan 80 MB, batas teoritisnya sekitar 15 worker. Angka ini bukan konfigurasi final karena masih perlu menyisakan ruang untuk Nginx, database, sistem operasi, cache, dan proses lain.

Ukur penggunaan aktual saat beban normal dan saat ramai. Worker yang tampak ringan pada halaman sederhana bisa jauh lebih boros ketika memproses laporan, pencarian kompleks, impor data, atau plugin pihak ketiga.

Cara membaca status PHP-FPM

PHP-FPM menyediakan status page yang dapat menampilkan jumlah koneksi diterima, antrean yang sedang menunggu, proses aktif, proses idle, penggunaan memori puncak, serta jumlah request lambat. Informasi ini jauh lebih berguna daripada sekadar melihat grafik CPU.

Contoh konfigurasi pada pool PHP-FPM:

pm.status_path = /fpm-status
ping.path = /fpm-ping

Setelah status page tersedia, perhatikan terutama tiga hal berikut:

1. listen queue. Jika nilainya sering naik, request sedang menunggu worker kosong.
2. max children reached. Jika nilainya lebih besar dari nol, batas proses pernah tersentuh sejak PHP-FPM dimulai.
3. slow requests. Angka ini membantu menunjukkan bahwa sebagian request melewati batas slowlog yang ditentukan.

Status page jangan dibuka untuk publik. Dokumentasi PHP memperingatkan bahwa halaman tersebut mengungkap informasi resource dan sebaiknya dibatasi untuk localhost, jaringan internal, atau alamat IP pemantauan. ([php.net](https://www.php.net/fpm.status.php?utm_source=openai))

Cari request yang membuat worker tertahan

Menaikkan jumlah worker hanya menutupi masalah jika akar penyebabnya adalah request yang lambat. Satu halaman bisa menahan worker karena menjalankan query database tanpa indeks, memanggil API eksternal yang tidak responsif, memproses gambar besar, atau melakukan pekerjaan berat langsung di dalam request pengguna.

Aktifkan slowlog dengan batas waktu yang masuk akal pada lingkungan yang sesuai:

request_slowlog_timeout = 5s
slowlog = /var/log/php-fpm/www-slow.log

Slowlog dapat membantu menunjukkan jejak eksekusi PHP ketika request berjalan terlalu lama. Setelah menemukan endpoint yang bermasalah, ukur bagian-bagiannya: waktu query MySQL, panggilan API, proses template, dan operasi file.

Untuk pekerjaan yang tidak perlu selesai sebelum pengguna menerima halaman, pertimbangkan memindahkannya ke antrean pekerjaan atau proses latar belakang. Mengirim email, membuat laporan PDF, atau memproses banyak gambar di request utama sering membuat worker cepat habis.

Peran Nginx: timeout bukan solusi performa

Nginx memiliki pengaturan seperti fastcgi_read_timeout untuk menentukan berapa lama menunggu respons dari PHP-FPM. Nilai bawaan yang terdokumentasi adalah 60 detik, tetapi menaikkan timeout tidak membuat PHP menjadi lebih cepat. Itu hanya memberi request waktu lebih lama sebelum dianggap gagal. ([nginx.org](https://nginx.org/en/docs/http/ngx_http_fastcgi_module.html?utm_source=openai))

Timeout yang terlalu pendek bisa memutus proses yang memang sah, misalnya ekspor data kecil yang membutuhkan waktu lebih lama. Namun, timeout yang terlalu panjang juga dapat membuat worker tertahan dan antrean semakin panjang. Gunakan timeout sebagai pagar pengaman, bukan sebagai pengganti optimasi kode.

Strategi pm yang perlu dipahami

PHP-FPM memiliki beberapa model pengelolaan worker. Mode dynamic menjaga sejumlah proses awal dan menambah proses ketika diperlukan. Mode ondemand membuat proses ketika ada request lalu dapat menghentikannya saat idle. Mode static mempertahankan jumlah proses sesuai konfigurasi.

Untuk banyak website biasa, dynamic sering menjadi titik awal yang masuk akal. Namun, pilihan terbaik bergantung pada pola trafik, kapasitas RAM, dan seberapa sering aplikasi menerima lonjakan request.

Pengaturan pm.max_requests juga layak diperhatikan. Nilai ini menentukan berapa banyak request yang dilayani setiap child process sebelum proses tersebut dibuat ulang. PHP mendokumentasikan pengaturan ini sebagai salah satu cara untuk mengurangi dampak kebocoran memori pada library pihak ketiga. ([php.net](https://www.php.net/manual/tr/install.fpm.configuration.php?utm_source=openai))

Yang bisa dilakukan sekarang

1. Aktifkan status PHP-FPM secara terbatas untuk alamat internal atau IP pemantauan.
2. Catat nilai listen queue, proses aktif, dan max children reached pada jam normal serta jam sibuk.
3. Aktifkan slowlog untuk menemukan endpoint yang menahan worker terlalu lama.
4. Periksa query database, API eksternal, proses upload, dan pekerjaan berat di request tersebut.
5. Hitung ulang pm.max_children berdasarkan RAM aktual, bukan menyalin angka dari server lain.
6. Atur timeout Nginx secara wajar setelah memahami durasi request yang memang diperlukan.

Intinya, PHP-FPM penuh adalah gejala, bukan diagnosis akhir. Kadang solusinya memang menambah worker. Namun, lebih sering hasil terbaik datang dari memperpendek request yang lambat, memindahkan pekerjaan berat ke proses latar belakang, dan memantau antrean sebelum pengguna mulai mengeluh.

Sumber & bacaan lebih lanjut

• PHP: FastCGI Process Manager (FPM)
• PHP-FPM Configuration Manual
• PHP-FPM Status Page
• Nginx FastCGI Module Documentation

– Rio Yotto @rioyotto