PHP-FPM Adalah: Cara Kerja, Kelebihan & Konfigurasinya

Saat browser meminta sebuah gambar atau berkas HTML, web server cukup membaca berkasnya di disk lalu mengirimkannya apa adanya. Berkas berakhiran .php tidak bisa diperlakukan seperti itu. Isinya masih berupa kode yang harus dijalankan lebih dulu supaya berubah menjadi HTML, sementara Nginx maupun Apache sama-sama tidak tahu cara menjalankan kode PHP.

Dari situ muncul pertanyaan yang jarang terpikir sampai server mulai melambat: siapa sebenarnya yang menjalankan kode tersebut? Pada mayoritas server modern jawabannya adalah PHP-FPM. PHP FPM adalah program terpisah yang menjalankan kode PHP dan mengelola sekumpulan proses pekerja yang mengerjakannya. Web server hanya mengantarkan permintaan dan membawa pulang hasilnya. Pembagian tugas ini layak dipahami karena hampir semua keluhan "website mendadak error 502" pada server yang sebenarnya sehat berakar dari satu angka di konfigurasi PHP-FPM.

Apa Itu PHP-FPM?

PHP-FPM adalah program resmi bawaan PHP yang menjalankan kode PHP sebagai layanan mandiri di luar web server. Keduanya berkomunikasi lewat protokol FastCGI. Secara teknis ia berbentuk SAPI (Server API, lapisan yang menghubungkan PHP dengan pihak yang memanggilnya). Di dalamnya berjalan satu proses induk (master) yang tidak pernah mengeksekusi kode, ditambah sejumlah proses pekerja (worker). Setiap worker mengerjakan satu permintaan pada satu waktu.

FPM singkatan dari apa?

FPM adalah singkatan dari FastCGI Process Manager. Ketiga kata itu sudah merangkum seluruh pekerjaannya:

1. FastCGI: protokol untuk memanggil program di luar web server. Berbeda dari CGI klasik yang menyalakan proses baru di setiap permintaan, FastCGI memakai proses yang sudah hidup. Biaya menyalakan interpreter PHP karena itu hanya dibayar sekali.
2. Process: satuan yang dikelolanya adalah proses sistem operasi, bukan thread. Setiap worker punya memorinya sendiri.
3. Manager: bagian yang paling sering diabaikan. PHP-FPM menentukan berapa worker yang dinyalakan, kapan menambah, kapan mematikan, dan apa yang terjadi pada permintaan yang datang saat semua worker sedang sibuk.

Perlu diperhatikan bahwa PHP-FPM bukan produk terpisah dari PHP. Ia awalnya patch eksternal buatan Andrei Nigmatulin, lalu masuk ke inti PHP pada rilis 5.3.3 tahun 2010. Karena berada di dalam kode sumber PHP, nomor versinya selalu mengikuti versi PHP — PHP 8.3 memakai PHP-FPM 8.3. Berakhirnya dukungan sebuah versi PHP otomatis mengakhiri dukungan FPM-nya.

Cara Kerja PHP-FPM: Master, Worker, dan Antrean

Perjalanan satu permintaan halaman PHP kira-kira begini. Browser meminta sebuah URL, Nginx menerimanya, menyadari berkas yang diminta berakhiran .php, lalu meneruskannya ke PHP-FPM melalui sebuah socket. Master menyerahkan permintaan itu ke worker yang menganggur, worker mengeksekusi kodenya sampai selesai, hasilnya berupa HTML dikembalikan ke Nginx, dan Nginx mengirimkannya ke browser.

Alur PHP-FPM: Nginx meneruskan berkas .php ke master, master membagi ke worker, sisanya menunggu di listen queue.

Tiga hal dari alur ini menjadi dasar seluruh pembahasan berikutnya.

Pertama, master tidak mengerjakan apa-apa selain mengatur. Ia mendengarkan socket, membagi pekerjaan, dan menyalakan pengganti worker yang mati. Beban CPU sesungguhnya ada di worker.

Kedua, jumlah worker terbatas dan ditentukan oleh Anda — bukan oleh jumlah pengunjung, bukan pula oleh sisa RAM. PHP-FPM tidak akan pernah melampaui batas yang Anda tulis, meskipun memori server masih longgar.

Ketiga, permintaan yang tidak kebagian worker tidak langsung ditolak. Ia masuk ke listen queue (antrean di tingkat socket) dan menunggu worker yang selesai. Selama antrean masih muat, pengunjung hanya merasakan halaman yang lambat. Begitu antrean penuh, barulah muncul kegagalan yang terlihat sebagai error 502.

Satu worker mengerjakan satu permintaan sampai tuntas. Jika sebuah halaman memerlukan tiga detik, satu worker terkunci selama tiga detik penuh dan tidak bisa melayani siapa pun. Inilah alasan skrip lambat jauh lebih berbahaya di PHP-FPM daripada yang diperkirakan banyak orang.

Bedanya dengan mod_php dan CGI Biasa

Secara historis ada tiga cara menjalankan PHP di balik web server, masing-masing menyelesaikan masalah yang ditinggalkan pendahulunya.

CGI klasik menyalakan satu proses PHP baru setiap kali ada permintaan, lalu membuangnya — aman tetapi mahal, karena biaya menyalakan interpreter dibayar berulang-ulang. Dua cara berikutnya menghapus biaya itu dengan pendekatan berbeda, dan perbandingan keduanyalah yang benar-benar Anda hadapi hari ini.

Kelemahan utama mod_php bukan soal kecepatan, melainkan kebebasan. Karena PHP menyatu ke dalam proses Apache, setiap child Apache membawa serta interpreter PHP walaupun yang dilayaninya hanya sebuah berkas CSS. Selain itu tidak semua ekstensi PHP pihak ketiga aman di lingkungan ber-thread, sehingga mod_php mengunci pilihan MPM Apache ke model berbasis proses. Dokumentasi Apache menyebut persoalan ekstensi non-thread-safe ini sebagai keluhan menahun pengguna mod_php sejak era Apache 2.2.

PHP-FPM memutus keterikatan itu. Karena PHP berjalan di prosesnya sendiri, Apache bebas memakai MPM mana pun. Nginx, yang tidak pernah punya modul PHP tertanam, pun bisa melayani PHP sama baiknya.

Keunggulan PHP-FPM di Server Produksi

Daftar berikut diambil dari fitur resmi yang tercantum di dokumentasi PHP.

1. Pool terpisah per situs: satu layanan PHP-FPM bisa menjalankan beberapa kelompok worker dengan pemilik proses, direktori terbatas, dan php.ini yang berbeda-beda. Kebocoran keamanan pada satu situs karena itu tidak otomatis membuka berkas tetangganya.
2. Graceful reload: konfigurasi dimuat ulang tanpa memutus permintaan yang sedang berjalan.
3. Slowlog yang benar-benar berguna: skrip yang melewati ambang waktu tertentu dicatat lengkap dengan jejak pemanggilan fungsinya, bukan sekadar nama berkasnya. Anda mendapat baris kode yang macet, bukan tebakan.
4. Halaman status bawaan: sebuah URL khusus yang menampilkan berapa worker sedang aktif, menganggur, dan berapa permintaan yang mengantre. Tersedia dalam format JSON, XML, dan OpenMetrics.
5. Emergency restart: menyalakan ulang dirinya sendiri saat mendeteksi sejumlah worker mati beruntun, misalnya karena opcode cache rusak.
6. fastcgi_finish_request(): mengirimkan jawaban ke pengunjung lebih dulu, lalu membiarkan skrip melanjutkan pekerjaan berat seperti mengolah statistik.

Satu hal perlu dijernihkan supaya harapan Anda tepat sasaran. Tidak satu pun kemampuan di atas membuat sebuah halaman PHP dieksekusi lebih cepat. Yang memangkas waktu eksekusi adalah OPcache, yaitu cache yang menyimpan hasil kompilasi kode PHP di memori, serta kualitas kode dan query aplikasi Anda. Peran PHP-FPM berbeda: ia menjaga performa tetap stabil saat ramai, bukan memangkas waktu eksekusi saat sepi.

Tiga Mode Process Manager dan Cara Memilihnya

Direktif pm menentukan bagaimana PHP-FPM mengelola jumlah workernya. Tersedia tiga pilihan, dan konsekuensinya berbeda jauh.

static menyalakan worker sebanyak pm.max_children sejak layanan dinyalakan, lalu jumlahnya tidak pernah berubah. Waktu tanggap paling stabil, tetapi memorinya dipakai penuh sepanjang waktu, ramai maupun sepi.

dynamic menyalakan sejumlah worker awal, lalu menambah dan mengurangi mengikuti beban dengan tetap menjaga beberapa worker cadangan yang menganggur. Ini pilihan bawaan dan cocok untuk sebagian besar situasi.

ondemand tidak menyalakan worker sama sekali sampai permintaan pertama datang, dan mematikan worker yang menganggur setelah melewati pm.process_idle_timeout yang nilai bawaannya (default) 10 detik. Pemakaian memori paling hemat, dengan konsekuensi permintaan pertama setelah masa sepi terasa sedikit lebih lambat.

Tiga mode PHP-FPM: static tetap penuh, dynamic naik-turun mengikuti beban, ondemand baru menyala saat ada permintaan.

Rekomendasi praktisnya sederhana. Untuk VPS kecil berisi banyak situs yang sebagian besar sepi, pakai ondemand. Untuk satu sampai tiga situs yang ramai wajar, pakai dynamic. Pakai static hanya jika server didedikasikan untuk satu aplikasi dan Anda tahu persis memori yang tersedia.

Khusus mode dynamic, pm.start_servers wajib berada di antara pm.min_spare_servers dan pm.max_spare_servers. Jika dilanggar, PHP-FPM menolak menyala:

ALERT: [pool www] pm.start_servers(20) must not be less than pm.min_spare_servers(1) and not greater than pm.max_spare_servers(3)
ERROR: failed to post process the configuration
ERROR: FPM initialization failed

Menghitung pm.max_children, Angka Paling Menentukan

Berkas konfigurasi pool bawaan yang dikirim bersama kode sumber PHP mengisi pm.max_children dengan angka 5. Lima worker berarti server Anda hanya sanggup mengerjakan lima permintaan PHP secara bersamaan. Untuk hosting bersama yang padat angka itu masuk akal, tetapi untuk VPS berisi satu atau dua situs, angka tersebut hampir selalu terlalu kecil.

Menggantinya tidak bisa dengan menebak. Rumusnya berangkat dari memori, bukan jumlah pengunjung:

pm.max_children = (RAM total − RAM untuk sistem operasi, database, dan web server) ÷ rata-rata RAM satu worker

Angka pembagi harus diukur, karena besar satu worker bergantung pada aplikasi dan ekstensi yang Anda pakai. Jalankan perintah berikut pada server yang sedang melayani trafik normal:

ps --no-headers -o rss,args -C php-fpm8.3 | grep 'pool' | awk '{sum+=$1; n++} END {if (n) printf "%d worker, rata-rata %.1f MB\n", n, sum/n/1024}'

Keluarannya berbentuk seperti 12 worker, rata-rata 50.5 MB. Sesuaikan php-fpm8.3 dengan versi PHP Anda, karena -C mencocokkan nama berkas program secara persis. Bagian grep 'pool' menyingkirkan proses master supaya rata-ratanya tidak ikut tertarik turun. Ukur beberapa kali di jam sibuk dan pakai angka tertinggi, bukan rata-rata harian.

Sebagai contoh, ambil VPS dengan RAM 4 GB yang menjalankan WordPress beserta MySQL. Sisihkan sekitar 700 MB untuk sistem operasi, 1 GB untuk MySQL, dan 200 MB untuk Nginx, sehingga tersisa kira-kira 2,1 GB untuk PHP. Jika satu worker terukur 50 MB, maka 2.100 ÷ 50 menghasilkan 42. Turunkan sekitar 20 persen sebagai bantalan, dan Anda mendapat angka aman di kisaran 34. Perhitungan sesederhana ini tidak membutuhkan kalkulator khusus — yang menentukan ketepatannya adalah angka hasil pengukuran, bukan rumusnya.

Dari RAM 4 GB tersisa 2,1 GB untuk PHP; dibagi 50 MB per worker lalu dikurangi 20 persen menghasilkan 34 worker.

Ada satu angka lagi di belakang perhitungan itu: batas memori per skrip (memory limit) yang diatur direktif memory_limit di php.ini. Nilainya jauh di atas pemakaian normal. Dengan memory_limit = 256M dan pm.max_children = 34, skenario terburuknya 34 × 256 MB — sekitar 8,7 GB di server yang hanya punya 4 GB. Skenario itu jarang terjadi karena tidak semua worker menyentuh batasnya bersamaan.

Meski begitu, pm.max_children dihitung dari pemakaian rata-rata, sementara memory_limit adalah batas atas yang tetap terbuka. Menurunkannya ke angka yang benar-benar dibutuhkan aplikasi mempersempit jarak keduanya.

Menaikkan angka ini terlalu tinggi bukan tindakan tanpa risiko. Anda hanya menukar satu masalah dengan masalah lain. Error 502 memang hilang, digantikan OOM killer yang mematikan MySQL saat memori habis — kegagalan yang jauh lebih sulit dipulihkan.

Menyetel angka ini membutuhkan akses ke berkas konfigurasi sistem, sesuatu yang umumnya baru Anda miliki di VPS Indonesia atau server sendiri. Pada hosting bersama, batasnya ditetapkan penyedia dan biasanya bisa dilihat lewat panel.

Konfigurasi Dasar dan Perintah yang Perlu Diingat

Pada Debian dan Ubuntu, PHP-FPM dipasang sebagai paket tersendiri yang namanya memuat nomor versi PHP. Ubuntu 24.04 LTS membawa PHP 8.3, sehingga perintahnya menjadi:

sudo apt update && sudo apt install php8.3-fpm
sudo systemctl enable --now php8.3-fpm

Perintah kedua menyalakan layanannya sekaligus mendaftarkannya supaya ikut hidup setiap kali server di-boot. Angka 8.3 dipakai sebagai contoh sepanjang artikel ini; ganti dengan versi yang terpasang di server Anda, yang bisa dilihat lewat ls /etc/php/.

Berkas pool bawaannya berada di /etc/php/8.3/fpm/pool.d/www.conf, sementara pengaturan global layanannya ada di /etc/php/8.3/fpm/php-fpm.conf. Blok berikut titik awal yang masuk akal untuk VPS 4 GB, dan sudah lolos pengujian konfigurasi PHP-FPM:

[www]
listen = /run/php/php8.3-fpm.sock
pm = dynamic
pm.max_children = 34
pm.start_servers = 6
pm.min_spare_servers = 4
pm.max_spare_servers = 10
pm.max_requests = 500
pm.status_path = /status
slowlog = /var/log/php-fpm-slow.log
request_slowlog_timeout = 5s
request_terminate_timeout = 55s

Dua baris layak dijelaskan. Direktif listen menentukan pintu masuk permintaan: berkas socket Unix seperti di atas, atau alamat TCP berisi nomor port. Port bawaan PHP-FPM adalah 9000, sehingga bentuk TCP-nya lazim ditulis 127.0.0.1:9000. Pakai socket Unix selama web server dan PHP-FPM satu mesin, karena lalu lintasnya tidak melewati tumpukan jaringan; TCP hanya jika keduanya terpisah mesin atau kontainer.

Baris pm.max_requests menyuruh worker mendaur ulang dirinya setiap 500 permintaan. Nilai bawaannya 0 — tidak pernah didaur ulang — sehingga kebocoran memori kecil menumpuk berhari-hari.

Setelah menyunting berkas tersebut, jalankan uji konfigurasi (config test) sebelum memuat ulang:

sudo php-fpm8.3 -t

Konfigurasi yang benar dijawab NOTICE: configuration file ... test is successful. Kesalahan penulisan dijawab dengan menyebut nomor barisnya, misalnya ERROR: [...www.conf:8] unknown entry 'pm.max_spare_serverz'.

Perhatikan satu hal saat memakai perintah ini di skrip otomatis: php-fpm -t tetap mengembalikan kode keluar 0 walaupun berkas konfigurasi gagal dimuat. Rangkaian perintah dengan && karena itu tidak bisa diandalkan untuk mendeteksi kegagalannya — baca keluarannya.

Setelah lolos uji, muat ulang konfigurasinya:

sudo systemctl reload php8.3-fpm

Perbedaan reload dan restart bukan sekadar selera. Perintah reload mengirim sinyal SIGUSR2 yang memicu pemuatan ulang secara graceful (bertahap, tanpa memutus pekerjaan yang berjalan), sehingga permintaan yang sedang diproses tetap selesai. Perintah restart menghentikan seluruh proses lebih dulu, dan permintaan yang berjalan ikut terputus. Untuk perubahan rutin, pakai reload.

Adapun pm.status_path mengaktifkan halaman status (status page), meski Anda masih perlu menambahkan satu blok location di Nginx supaya alamat itu bisa dibuka. Dua angka di sana paling layak diperhatikan. Pertama listen queue, jumlah permintaan yang sedang mengantre. Kedua max children reached, yang bernilai lebih dari nol jika batas worker pernah tersentuh.

Halaman yang sama bisa dikeluarkan dalam format JSON dan OpenMetrics, sehingga angkanya dapat ditarik ke sistem monitoring tanpa diurai manual. OpenMetrics adalah format yang dibaca Prometheus, dan tersedia pula exporter pihak ketiga. Template PHP-FPM bawaan Zabbix membaca halaman ini juga.

Membaca Error 502 dan 504 pada PHP-FPM

Dua kode error ini paling sering muncul dan paling sering tertukar. Keduanya berpangkal pada jumlah worker, tetapi menunjukkan gejala yang berbeda.

Error 502 berarti Nginx tidak mendapatkan jawaban sama sekali. Penyebab paling umum: seluruh worker sibuk dan antrean socket sudah penuh, sehingga koneksi baru ditolak. Buktinya ada di log PHP-FPM berupa baris WARNING: [pool www] server reached pm.max_children setting. Penyebab kedua, terutama saat pertama memasang, adalah izin berkas socket yang tidak terbaca oleh pengguna yang menjalankan Nginx.

Error 504 berarti jawaban tidak datang tepat waktu. Nginx menunggu selama fastcgi_read_timeout yang nilai bawaannya 60 detik, lalu menyerah. Permintaannya sendiri tidak gagal — ia hanya kelamaan.

Di sinilah letak ketidakcocokan bawaan yang layak Anda perbaiki sejak awal. Nginx berhenti menunggu pada detik ke-60, sementara request_terminate_timeout di PHP-FPM bawaannya 0 alias tidak aktif. Akibatnya worker yang mengerjakan skrip macet itu terus berjalan setelah pengunjung menerima halaman 504, dan tetap menahan slotnya. Jika beberapa permintaan seperti itu datang beruntun, satu skrip lambat bisa menghabiskan seluruh worker dan menjatuhkan situs.

Sebenarnya ada tiga batas waktu (timeout) berlapis pada satu permintaan PHP, dan urutannya menentukan siapa yang berhenti lebih dulu:

1. max_execution_time di php.ini: batas terdalam, menghitung waktu eksekusi kode saja — bukan waktu menunggu database atau jaringan.
2. request_terminate_timeout di PHP-FPM: batas keras tingkat worker, menghitung seluruh durasi permintaan termasuk waktu menunggu tadi.
3. fastcgi_read_timeout di Nginx: batas terluar, berapa lama Nginx bersedia menunggu jawaban.

Susunan yang sehat membuat batas terdalam habis lebih dulu — misalnya 30, 55, dan 60 detik — sehingga worker dibebaskan sebelum Nginx menyerah. Kalau terbalik, pengunjung menerima 504 sementara workernya tetap sibuk.

Di PHP-FPM, 502 berarti semua worker sibuk dan antrean penuh; 504 berarti permintaan melewati batas 60 detik nginx.

Perlu diperhatikan bahwa menaikkan pm.max_children hanya benar untuk baris pertama tabel. Untuk baris lainnya, angka yang lebih besar justru memperbanyak proses yang sama-sama macet.

Saat php-fpm memakan CPU sampai 100 persen

Pola gejalanya khas: top menampilkan baris php-fpm: pool www yang bertahan di angka tinggi, sementara beban kunjungan biasa saja. Proses master PHP-FPM sendiri hampir tidak memakai CPU karena tugasnya hanya membagi pekerjaan. Angka tinggi yang Anda lihat selalu milik worker, dan yang memakannya adalah kode aplikasi yang sedang dijalankan worker itu.

Tiga penyebab paling sering: perulangan yang tidak pernah berhenti, query database tanpa indeks pada tabel yang membesar, dan plugin yang berjalan di setiap permintaan. Ketiganya dikenali dengan cara yang sama, yaitu membaca slowlog. Halaman status format lengkap juga menampilkan skrip yang sedang dijalankan tiap worker beserta durasinya.

Menaikkan pm.max_children saat CPU sudah penuh justru memperburuk keadaan. Worker tambahan akan berebut CPU yang sama, sehingga seluruh permintaan melambat, bukan hanya yang bermasalah.

Kekurangan dan Hal yang Perlu Anda Pertimbangkan

Lima hal berikut layak Anda ketahui sebelum memutuskan, dan sebagian di antaranya baru terasa setelah server berjalan beberapa bulan.

1. Ada satu layanan tambahan yang bisa mati sendiri: dengan mod_php, PHP hidup dan mati bersama Apache. Dengan PHP-FPM, ada proses kedua yang harus ikut dipantau. Server yang tampak menyala namun mengembalikan 502 di semua halaman biasanya berarti layanan ini berhenti.
2. Memori tidak gratis: setiap worker memegang memorinya sampai didaur ulang. Menyetel pm.max_children terlalu tinggi tanpa menghitung memori yang tersedia adalah cara tercepat mengundang OOM killer.
3. Nilai bawaannya hampir pasti salah untuk server Anda: lima worker aman bagi penyedia hosting, bukan optimal bagi satu VPS. Tanpa penyetelan, sebagian besar keunggulan PHP-FPM tidak akan terasa.
4. Tidak ada versi Windows: kode sumber PHP menyediakan skrip build Windows untuk SAPI CGI, tetapi tidak untuk FPM. Direktori FPM hanya berisi berkas konfigurasi autoconf khusus sistem mirip Unix. Sejumlah panduan menyebut php-cgi.exe sebagai PHP-FPM versi Windows, dan itu tidak tepat: keduanya SAPI berbeda, dan php-cgi.exe tidak mengenal satu pun direktif pm.*. Di Windows, penggunanya bergantung pada IIS beserta manajemen prosesnya sendiri.
5. Modelnya satu proses per permintaan: setiap permintaan memulai aplikasi dari nol. Alternatif seperti FrankenPHP, Swoole, RoadRunner, dan Laravel Octane menahan aplikasi tetap hidup di memori antar permintaan sehingga waktu tanggapnya lebih singkat. Peningkatan itu nyata, tetapi menuntut kode yang stateless (tidak meninggalkan sisa keadaan antar permintaan), karena variabel global yang bocor akan terbawa ke pengunjung berikutnya. Sebagian besar situs yang berjalan wajar tidak perlu berpindah.

Pertanyaan yang Sering Diajukan

PHP-FPM untuk apa sebenarnya? Untuk menjalankan kode PHP di luar web server dan mengatur berapa banyak permintaan yang boleh dikerjakan bersamaan. Web server mengurus berkas statis dan lalu lintas HTTP, PHP-FPM mengurus eksekusi kode beserta batas kapasitasnya.

Apakah PHP-FPM harus dipakai dengan Nginx? Tidak. PHP-FPM bekerja dengan web server apa pun yang mengerti FastCGI; Apache menyambungkannya lewat modul mod_proxy_fcgi. Pasangannya dengan Nginx populer karena Nginx memang tidak punya cara lain menjalankan PHP.

Apakah hosting bersama saya sudah memakai PHP-FPM? Kemungkinan besar sudah. Sebagian besar panel modern, termasuk cPanel, menyediakannya sebagai pilihan penanganan PHP dan mengaktifkannya sebagai bawaan. Batas workernya diatur penyedia dan umumnya tidak dapat Anda ubah sendiri.

Kenapa PHP-FPM tidak tersedia di Windows? Karena rancangannya bergantung pada mekanisme penggandaan proses khas sistem mirip Unix, sehingga kode sumber PHP tidak menyediakan jalur build Windows untuk FPM. Kalau aplikasi Anda memang harus berjalan di Windows, manajemen prosesnya diserahkan ke IIS. Cara lain yang lebih lazim adalah menjalankan PHP-FPM di dalam WSL atau container Linux.

Bagaimana PHP-FPM dipakai di dalam Docker? Image resmi PHP menyediakan varian bertanda -fpm (misalnya php:8.3-fpm dan versi ringan php:8.3-fpm-alpine) yang sudah berisi PHP-FPM siap jalan. Pola yang lazim adalah dua container terpisah, satu Nginx dan satu PHP-FPM. Keduanya dihubungkan lewat TCP port 9000, karena socket Unix tidak melintasi batas container, dan tetap perlu berbagi direktori kode aplikasi.

Apakah PHP-FPM membuat website menjadi lebih cepat? Tidak secara langsung. Satu halaman tidak dieksekusi lebih cepat hanya karena berpindah ke PHP-FPM. Yang membaik adalah performa saat ramai, yaitu jumlah permintaan yang sanggup dilayani bersamaan. Untuk memangkas waktu eksekusi, aktifkan OPcache dan perbaiki query aplikasi Anda.

Kesimpulan

PHP-FPM adalah manajer proses yang menjalankan kode PHP di luar web server, dengan sekumpulan worker berjumlah terbatas yang Anda tentukan sendiri. Nilai utamanya bukan pada kecepatan satu halaman, melainkan pada berubahnya kapasitas server dari sesuatu yang samar menjadi angka yang bisa dihitung, diukur, dan diperbaiki.

Jika Anda memakainya, dua hal layak dikerjakan sejak awal. Pertama, ganti pm.max_children bawaan yang bernilai 5 dengan hasil hitungan memori server Anda. Kedua, isi request_terminate_timeout supaya tidak ada worker yang menahan slotnya setelah pengunjung menyerah menunggu. Dua penyetelan itu saja menutup sebagian besar penyebab error 502 dan 504 pada server yang sehat.

Semoga artikel ini membantu.