Jika halaman website kadang cepat, lalu mendadak lambat terutama saat membuka dashboard, login, atau halaman dinamis, masalahnya belum tentu bandwidth atau jumlah trafik. Sering kali bottleneck berada di PHP-FPM: lapisan yang menjalankan kode PHP sebelum server mengirimkan HTML kepada pengunjung.
PHP-FPM bekerja dengan sejumlah proses atau worker. Setiap worker menangani request PHP. Jika semua worker sedang sibuk, request baru masuk ke antrean. Pengunjung akhirnya melihat waktu tunggu panjang, sementara pemilik website mungkin hanya melihat angka trafik yang tampak normal.
Mengapa PHP-FPM bisa menjadi titik macet?
Bayangkan sebuah kedai dengan lima kasir. Lima kasir itu adalah worker PHP-FPM. Ketika pesanan sederhana datang, satu kasir dapat melayani banyak pelanggan dengan cepat. Namun jika ada satu pesanan yang membutuhkan waktu lama—misalnya query database berat, panggilan API eksternal, atau proses pembuatan laporan—kasir tersebut tertahan lebih lama.
Masalah muncul ketika beberapa worker mengalami hal yang sama. Batas pm.max_children menentukan jumlah maksimum request PHP yang dapat dilayani secara bersamaan. Jika seluruh child process sedang digunakan, request berikutnya tidak langsung diproses. Dokumentasi PHP menjelaskan bahwa parameter ini berfungsi sebagai batas concurrent request untuk PHP-FPM.
Namun, menaikkan angka pm.max_children secara membabi buta bukan solusi. Setiap worker menggunakan memori. Jika jumlahnya terlalu besar, server bisa mengalami tekanan RAM, mulai melakukan swap, atau bahkan mematikan proses karena kehabisan memori. Website mungkin tampak lebih kuat untuk beberapa menit, lalu justru semakin tidak stabil.
Tanda-tanda worker PHP-FPM mulai kehabisan kapasitas
Gejalanya tidak selalu sama, tetapi beberapa pola berikut cukup umum:
- TTFB meningkat pada halaman yang membutuhkan PHP, sementara file statis tetap cepat.
- Website cepat setelah cache dibersihkan, tetapi lambat kembali ketika halaman dinamis mulai banyak diakses.
- Log PHP-FPM menunjukkan pesan seperti max children reached.
- CPU tidak selalu 100 persen, tetapi load average, penggunaan RAM, atau jumlah proses PHP terus tinggi.
- Request tertentu membutuhkan waktu jauh lebih lama daripada request lain.
- Dashboard admin lambat, sedangkan halaman publik yang sudah tercache masih terasa normal.
Status PHP-FPM dapat membantu mengonfirmasi dugaan tersebut. Salah satu indikator penting adalah apakah jumlah maksimum child process pernah tercapai. Status page PHP-FPM juga dapat menampilkan informasi seperti jumlah proses aktif dan request yang tergolong lambat.
Jangan mulai dengan menambah worker
Langkah yang lebih aman adalah mencari tahu mengapa worker bertahan terlalu lama. Jumlah worker yang sedikit memang bisa menjadi masalah, tetapi worker yang lama selesai juga sering menjadi akar persoalan.
1. Aktifkan slowlog secara hati-hati
PHP-FPM menyediakan mekanisme slowlog untuk mencatat backtrace request yang melewati batas waktu tertentu. Atur request_slowlog_timeout pada nilai yang masuk akal, misalnya beberapa detik, lalu tentukan lokasi slowlog.
Tujuannya bukan mencatat semua request, melainkan menemukan kode yang menahan worker terlalu lama. Setelah data terkumpul, periksa apakah sumbernya berasal dari query database, loop besar, pemanggilan API, plugin, atau proses lain yang berjalan secara sinkron.
2. Bedakan bottleneck CPU, memori, dan waktu tunggu
Worker PHP yang aktif tidak selalu berarti CPU sedang bekerja keras. Sebuah request bisa saja hanya menunggu database atau koneksi ke layanan pihak ketiga. Karena itu, periksa metrik server secara bersamaan:
- CPU tinggi: kemungkinan ada komputasi berat, parsing besar, atau terlalu banyak proses berjalan.
- RAM menipis: jumlah worker mungkin terlalu besar atau aplikasi menggunakan memori berlebihan.
- CPU rendah tetapi request lama: curigai database, disk, jaringan, atau API eksternal.
- Disk I/O tinggi: periksa logging berlebihan, operasi file, backup, atau database yang sering membaca data dari disk.
Melihat satu grafik saja sering menghasilkan kesimpulan yang keliru. Website dapat memiliki CPU rendah tetapi tetap lambat karena semua worker sedang menunggu resource lain.
3. Cari request yang tidak seharusnya berjalan di jalur pengguna
Beberapa pekerjaan tidak perlu dilakukan saat pengunjung menunggu halaman selesai. Contohnya membuat thumbnail dalam jumlah besar, mengirim email, menghitung laporan, sinkronisasi stok, atau mengambil data dari API eksternal.
Pindahkan pekerjaan tersebut ke cron, queue, atau proses background jika arsitektur aplikasi memungkinkan. Dengan begitu, request web hanya membuat tugas dan segera mengembalikan respons, sementara pekerjaan panjang diproses di luar jalur interaksi pengguna.
Cara menentukan nilai pm.max_children
Nilai yang tepat bergantung pada RAM dan konsumsi memori setiap worker. Jangan menyalin angka dari server lain. Ukur terlebih dahulu penggunaan memori proses PHP saat beban normal, lalu sisakan ruang untuk sistem operasi, web server, database, dan layanan lain.
Secara sederhana, pendekatannya dapat digambarkan seperti ini:
worker_maksimum = RAM yang dialokasikan untuk PHP-FPM / rata-rata RAM satu workerHasil perhitungan tersebut bukan angka final. Sisakan margin agar lonjakan penggunaan memori tidak langsung membuat server kehabisan RAM. Setelah mengubah konfigurasi, pantau penggunaan memori, jumlah request, waktu respons, dan error selama beberapa periode sibuk.
Jika server memiliki RAM 4 GB dan aplikasi database berjalan pada mesin yang sama, seluruh memori tentu tidak boleh dialokasikan untuk PHP-FPM. Database juga memerlukan ruang untuk buffer dan koneksi. Inilah alasan konfigurasi PHP-FPM perlu dilihat sebagai bagian dari sistem, bukan pengaturan terpisah.
Jangan lupa memeriksa database dan cache
PHP-FPM sering menjadi tempat gejala terlihat, bukan tempat masalah dimulai. Satu query lambat dapat menahan worker selama beberapa detik. Jika query tersebut dipanggil pada setiap request, antrean akan terbentuk meski trafik tidak besar.
Periksa query yang paling sering dipanggil dan waktu eksekusinya. Gunakan slow query log atau Performance Schema untuk mengelompokkan pola statement dan melihat query yang paling banyak menghabiskan waktu. Setelah itu, periksa rencana eksekusi, indeks, jumlah baris yang dibaca, dan apakah data yang sama bisa dilayani melalui object cache.
Cache juga perlu digunakan dengan tepat. Cache halaman dapat mengurangi beban PHP untuk halaman publik, sedangkan object cache membantu menyimpan hasil query atau objek yang sering digunakan. Tetapi jangan meng-cache data yang bersifat personal tanpa mekanisme pemisahan yang jelas. Halaman akun, keranjang belanja, dan hasil pencarian pengguna biasanya memerlukan perlakuan berbeda dari halaman artikel publik.
Yang bisa dilakukan sekarang
- Catat kapan website lambat dan halaman mana yang terdampak.
- Bandingkan halaman statis, halaman publik dinamis, dan dashboard admin.
- Periksa status PHP-FPM dan cari indikator max children reached.
- Aktifkan slowlog untuk menemukan request yang terlalu lama.
- Ukur penggunaan memori rata-rata setiap worker sebelum menaikkan
pm.max_children. - Periksa query database dan panggilan API yang berlangsung di dalam request.
- Pindahkan pekerjaan panjang ke cron atau queue jika memungkinkan.
- Uji perubahan satu per satu, lalu bandingkan TTFB, error rate, RAM, CPU, dan waktu respons.
Apa artinya bagi kita?
Website lambat tidak selalu membutuhkan server yang lebih mahal. Kadang masalahnya adalah antrean kecil yang disebabkan oleh satu proses panjang, query yang tidak efisien, atau konfigurasi worker yang tidak sesuai dengan kapasitas RAM.
Perbaikan yang baik bukan sekadar membuat angka worker lebih besar. Tujuannya adalah membuat setiap request selesai lebih cepat, mengurangi pekerjaan yang dilakukan secara sinkron, dan memastikan database serta cache membantu PHP-FPM—bukan membuatnya menunggu lebih lama.
Sumber & bacaan lebih lanjut
- PHP Manual: PHP-FPM Configuration
- PHP Manual: PHP-FPM Status Page
- web.dev: Optimize Largest Contentful Paint
- MySQL Reference Manual: Statement Digests
- MDN: Cache-Control Header
– Rio Yotto @rioyotto