PHP-FPM

PHP-FPM (FastCGI Process Manager) menjalankan kode PHP sebagai proses terpisah yang menerima pekerjaan lewat FastCGI dari web server seperti Nginx atau Apache. Bedanya dengan PHP sebagai modul Apache: di modul, eksekusi terjadi di dalam proses web server; di FPM, ada satu master process yang mengelola kumpulan worker. Satu worker melayani satu skrip pada satu waktu, jadi kapasitas konkurensi ditentukan oleh jumlah worker di pool. Karena setiap worker memuat engine PHP dan aplikasinya sendiri, FPM menuntut perencanaan memori yang lebih hati-hati dibanding mode modul.

Model master dan worker

Master membaca konfigurasi pool dan menjaga jumlah worker sesuai aturan. Direktif pm.max_children adalah langit-langit praktis: sebanyak itu worker yang boleh hidup bersamaan, dan angka inilah yang membatasi berapa request PHP dilayani serentak. pm.start_servers, pm.min_spare_servers, dan pm.max_spare_servers hanya berlaku di mode dynamic; mode static menahan jumlah tetap, sedangkan ondemand menyalakan worker hanya saat diminta.

Mengatur pool

Di VPS, pool didefinisikan di file www.conf dan perubahan baru berlaku setelah FPM di-reload, misalnya systemctl reload php-fpm. Hitung pm.max_children dari RAM yang tersedia untuk PHP dibagi pemakaian rata-rata satu worker, bukan dari angka terbesar yang muat. systemctl status php-fpm menunjukkan apakah service hidup dan berapa worker berjalan. Menaikkan max_children setinggi mungkin hanya memindahkan masalah dari antrean ke memori: saat RAM habis, server mulai swap dan situs jadi lebih lambat daripada kalau mengantre sebentar.

Melihat pool yang sedang bekerja

Kalau pm.status_path diaktifkan, endpoint status bisa dibuka untuk melihat proses aktif, worker idle, dan berapa kali pool menyentuh pm.max_children. Di LiteSpeed atau CloudLinux, halaman resource panel menampilkan pemakaian per akun. Yang paling penting ada di log FPM: pesan server reached pm.max_children setting adalah tanda jelas bahwa pool perlu diperbesar atau skrip perlu dipercepat.

Ketika worker habis

Begitu semua worker sibuk, request baru mengantre di backlog; kalau antrean penuh, server menolak dengan Error 503. Ini mudah disalahpahami: yang habis adalah worker, bukan RAM atau CPU, sehingga monitor resource bisa terlihat aman padahal situs lambat. Di shared hosting, model serupa datang sebagai batas Entry Processes, dan LiteSpeed memakai mekanisme LSAPI yang berperan mirip.

Yang mengikat satu slot terlalu lama

Satu proses yang macet bisa menyerupai masalah besar. Worker yang menunggu query lambat atau panggilan API eksternal menahan slotnya sampai selesai, dan beberapa proses macet saja cukup untuk menghabiskan pool. Di shared hosting, proses yang sama juga menyita satu slot entry-process selama ia menunggu, misalnya pada cron job yang memanggil URL berat berulang kali. Karena itu gejalanya sering intermiten: normal di jam sepi, macet di jam ramai.

FAQ