Server dengan RAM besar dan CPU modern tetap bisa menampilkan error 504 saat flash sale tiba. Penyebabnya sering bukan traffic semata, melainkan kehabisan php worker wordpress: unit proses yang mengeksekusi setiap request dinamis satu per satu. Ketika antrean checkout menumpuk melebihi jumlah worker, pengunjung menunggu hingga timeout meski CPU terlihat santai. Panduan ini membedah definisi, cara kerja, rumus alokasi berbasis RAM, tiga mode PHP-FPM, langkah optimasi konkret, dan bahaya menambah worker sembarangan. Kamu akan tahu kapan menambah worker membantu, kapan optimasi query lebih murah, dan paket mana yang cocok.
Apa Itu PHP Worker dan Bagaimana Cara Kerjanya?
Istilah apa itu php worker terjawab sederhana: PHP worker adalah proses latar belakang PHP-FPM yang mengeksekusi satu request dinamis dari awal sampai selesai. Web server menerima koneksi, lalu meneruskan pekerjaan dinamis ke pool worker yang jumlahnya terbatas. Analogi restoran cepat saji membantu: web server adalah resepsionis yang membagikan menu kepada ribuan orang, sedangkan worker adalah koki dapur yang memasak pesanan khusus satu per satu. Kapasitas dapur inilah batas concurrency dinamis situsmu.
Satu worker melayani tepat satu request dalam satu waktu. Request itu bisa berupa eksekusi checkout, validasi login, atau render halaman yang tidak tersimpan di cache. Setelah selesai, worker bebas menerima request berikutnya. Selama eksekusi, ia tidak bisa disambi: inilah alasan request lambat menahan kapasitas. Detail eksekusi bytecode PHP dibahas di artikel OPcache WordPress sebagai pelengkap.
Perbedaan Penanganan Konten Statis dan Request Dinamis
Inilah inti fungsi php worker wordpress: hanya request dinamis yang butuh worker. Artikel di page cache, berkas CSS dan JS, serta gambar produk dikirim tanpa menyentuh PHP. Delapan pola berikut menunjukkan garis batasnya.
Di sisi transport, HTTP/2 dan HTTP/3 memengaruhi cara browser mengantre aset, melengkapi kapasitas worker di sisi server.
| Jenis Request | Jalur Pemrosesan | Menggunakan PHP Worker? | Dampak Beban Server |
|---|---|---|---|
| Artikel Blog (Cached) | Web Server / Page Cache | Tidak | Sangat rendah (hanya transfer HTML statis) |
| Berkas Aset (CSS, JS, Gambar) | Web Server / CDN Edge | Tidak | Nol beban proses PHP |
| Tambah ke Keranjang (Add to Cart) | PHP-FPM -> WooCommerce Logic | Ya (1 Worker) | Sedang (menulis sesi keranjang ke database) |
| Halaman Checkout WooCommerce | PHP-FPM -> Kalkulasi Pajak dan Diskon | Ya (1 Worker) | Tinggi (query dinamis kompleks dan integrasi) |
| Proses Pembayaran Gateway | PHP-FPM -> API Eksternal | Ya (1 Worker) | Tinggi (menyandera worker menunggu respon API) |
| Pencarian Produk (Katalog Dinamis) | PHP-FPM -> MySQL Query | Ya (1 Worker) | Tinggi bila query pencarian tidak di-cache |
| Halaman Dashboard wp-admin | PHP-FPM -> Validasi Cookie dan Hook | Ya (1 Worker) | Sedang hingga tinggi tergantung jumlah plugin |
| Cron Job Eksternal / CLI | PHP CLI / Background Daemon | Terpisah | Tergantung beban task latar belakang |
Web server berbasis event seperti LiteSpeed dan NGINX menyajikan konten cached ke ribuan koneksi paralel. Perbandingannya ada di Nginx vs OpenLiteSpeed: makin banyak request dijawab dari cache, makin sedikit worker yang dibutuhkan.
Mengapa Server Timeout (504 Gateway Timeout) Saat CPU Rendah?
Fenomena php worker woocommerce paling membingungkan adalah error 504 saat CPU hanya 15 persen. Penyebabnya adalah worker starvation: semua worker tersandera request lambat sehingga request baru menunggu sampai batas timeout, lalu menerima 504 Gateway Timeout.
Contoh: empat worker melayani empat checkout yang menunggu respons payment gateway lima detik. Selama itu kapasitas dinamis server nol: request kelima dan seterusnya menumpuk di antrean. Tugas terjadwal yang berjalan sebagai pseudo request memperparah antrean; solusinya dibahas di disable WP-Cron.
Menambah PHP worker pada server yang memiliki query lambat sama seperti menambah kasir di toko yang sistem pembayarannya sedang rusak. Masalahnya bukan kekurangan orang, melainkan waktu pelayanan yang terlalu lama.
Aturan praktisnya: ukur durasi request dinamis sebelum menambah worker. Satu query yang dipercepat dari lima detik menjadi setengah detik membebaskan worker sepuluh kali lebih cepat.
Menghitung Kebutuhan PHP Worker Berdasarkan RAM
Rumus cara menghitung php worker bertumpu pada memori, bukan CPU. Bagilah RAM bebas yang dialokasikan untuk PHP dengan rata-rata konsumsi satu proses: pm.max_children sama dengan RAM bebas dibagi memori per proses. Nilai rata-rata diukur dari server produksi memakai ps atau status pool PHP-FPM, bukan angka brosur.
Simulasi pertama: server 4GB dengan 2,4GB dialokasikan untuk PHP dan rata-rata 80MB per proses menghasilkan 30 worker. Simulasi kedua: server 8GB dengan 5GB untuk PHP dan rata-rata 80MB menghasilkan sekitar 60 worker. Sisakan selalu ruang untuk MySQL, sistem operasi, dan lonjakan cache agar server tidak kehabisan napas.
Catat hasilnya di berkas www.conf dan uji di jam sepi. Angka ini adalah langit-langit aman alokasi RAM, bukan target yang wajib penuh. Ukur ulang tiap kali plugin besar dipasang.
Tiga Mode Konfigurasi PHP-FPM: Static, Dynamic, dan Ondemand
Direktif pm mengatur cara pool melahirkan proses. Mode static menjaga jumlah worker tetap sesuai pm.max_children: tanpa jeda forking, latensi stabil, cocok untuk VPS dengan traffic harian yang dapat diprediksi. Harganya adalah memori yang selalu terisi penuh meski malam hari sepi.
Mode dynamic menaikkan dan menurunkan worker di antara pm.min_spare_servers dan batas maksimum mengikuti traffic. Fleksibel untuk traffic berfluktuasi, tetapi tiap kelahiran proses menambah jeda kecil. Mode ondemand melahirkan worker hanya saat request datang: hemat memori untuk situs sepi, tetapi tidak cocok untuk flash sale karena jeda awal menumpuk antrean.
Untuk toko bervolume tinggi di VPS, gunakan mode static untuk traffic stabil dengan angka hasil rumus sebelumnya.
Cara Mengoptimalkan dan Memantau PHP Worker WordPress
Menambah worker tanpa memperbaiki query lambat sama dengan memboroskan memori server percuma: antrean tetap menumpuk, hanya kapasitas antreannya yang lebih besar. Tiga langkah berikut berurutan dari diagnosis, penyesuaian konfigurasi, sampai pelepas beban memakai cache objek. Kerjakan berurutan supaya tiap perubahan terukur. Catat metrik sebelum dan sesudah agar efeknya terbukti. Fokusnya adalah memangkas durasi tiap request sehingga worker yang sama melayani pengunjung berkali lipat lebih banyak. Setiap detik yang dipangkas dari durasi request adalah kapasitas gratis untuk semua pengunjung berikutnya.
Menganalisis Request Dinamis dan Mengidentifikasi Bottleneck
Mulai dari log akses web server: sortir URL dengan waktu respons terlama dan frekuensi tertinggi. Hidupkan request_slowlog_timeout pada pool PHP-FPM agar request yang melebihi ambang tercatat di slow log lengkap dengan stack trace. Tersangka klasik adalah pencarian tanpa indeks, hook checkout dari plugin berat, dan panggilan AJAX admin yang berjalan tiap detik. Nonaktifkan atau cache-kan tersangka sebelum menyentuh angka worker. Satu plugin yang diperbaiki sering membebaskan kapasitas setara belasan worker baru.
Menyesuaikan Konfigurasi Pool PHP-FPM di Server
Buka berkas www.conf pada pool yang melayani domain toko, lalu setel pm.max_children sesuai hasil rumus dan pm.start_servers secukupnya untuk traffic normal. Pasang pm.max_requests bernilai moderat agar worker didaur ulang berkala dan memory leak tidak menumpuk. Contoh blok ringkas untuk server 4GB:
pm = static
pm.max_children = 30
pm.start_servers = 10
pm.max_requests = 500Muat ulang PHP-FPM di jam sepi, pantau memori selama 24 jam, dan naikkan bertahap bila antrean masih terbentuk. Jangan menaikkan dua kali lipat sekaligus karena risiko kehabisan RAM melonjak tajam.
Memasang Redis Object Cache untuk Meringankan Beban Worker
Hubungkan WordPress ke Redis agar hasil query berulang tersimpan di RAM: worker mengambil jawaban dari memori, bukan mengulang query ke MySQL. Durasi eksekusi yang semula 400ms dapat terpangkas menjadi 80ms, sehingga throughput worker yang sama naik hingga lima kali lipat kapasitas tanpa menambah RAM. Panduan pemasangannya ada di Redis Object Cache WordPress. Pola ini paling terasa pada php worker woocommerce saat katalog dicek ribuan kali per menit.
Mengapa Menambah PHP Worker Sembarangan Berbahaya bagi Server?
Tiap worker mengunci puluhan megabyte RAM selama hidupnya. Bila pm.max_children melebihi kapasitas fisik, server memakai swap dan respons melambat drastis. Pada titik kritis, kernel Linux mengaktifkan OOM Killer Linux: proses besar seperti MySQL atau PHP-FPM dimatikan paksa agar sistem selamat. Hasilnya bukan situs lambat, melainkan crash total dengan database yang berhenti.
Simulasi antrean berikut menunjukkan bagaimana empat worker yang tersandera request lima detik memicu 504 beruntun pada request berikutnya.
Batas aman selalu menyisakan ruang untuk MySQL, sistem, dan lonjakan cache. Pantau memori puncak selama seminggu termasuk jam promo sebelum menetapkan angka final, dan naikkan bertahap lima sampai sepuluh worker per siklus evaluasi.
Rekomendasi Infrastruktur Hosting untuk Toko Online Dinamis
Untuk blog dan toko rintisan, Cloud Hosting Mordenhost berbasis LiteSpeed Web Server memproses aset statis dan cache tanpa menyita kapasitas worker. Performa PHP tetap kencang untuk checkout harian normal tanpa perlu menyentuh konfigurasi server.
Bila ratusan checkout berjalan bersamaan, Managed VPS Mordenhost memberi RAM dedicated dengan tuning pm.max_children kustom oleh tim ahli dan monitoring 24/7 mulai Rp950.000 per bulan. Diskusikan pola traffic lewat WhatsApp Mordenhost agar alokasi worker sesuai kebutuhan nyata, bukan tebakan. Pilih berdasarkan kebutuhan kontrol dan volume transaksi: mulai dari cloud untuk validasi pasar, naik ke VPS saat antrean checkout rutin terbentuk. Migrasi lebih murah daripada downtime berulang tiap promo.
Kesimpulan
PHP worker adalah batas kapasitas konkurensi dinamis WordPress: jumlah request uncached yang bisa dimasak bersamaan dalam satu waktu.
Kombinasi query yang ramping, cache objek di memori, dan angka worker sesuai RAM menjaga toko stabil saat promo. Menambah worker adalah langkah terakhir, bukan yang pertama. Kalau fondasi hosting secara umum masih kabur, baca dulu memahami cara kerja hosting sebelum mengutak-atik pool PHP-FPM.
Ukur, optimasi, lalu tambah kapasitas sesuai data: itulah urutan yang membuat server awet dan checkout lancar setiap hari, bukan hanya saat traffic sepi.
Pertanyaan yang Sering Ditanya
Empat jawaban singkat untuk pertanyaan paling umum soal PHP worker, antrean request, dan alokasi RAM di WordPress, berdasarkan kebingungan yang sering muncul.
Berapa jumlah PHP worker standar untuk website WordPress?
Paket shared umumnya menyediakan dua sampai empat worker per situs. Toko online ramai biasanya butuh delapan sampai enam belas worker, disesuaikan RAM tersedia dan durasi rata-rata tiap request dinamis.
Apakah halaman yang sudah di-cache memakai PHP worker?
Tidak. Halaman yang tersimpan di page cache atau CDN dijawab langsung web server tanpa menyentuh PHP. Worker hanya bekerja untuk request dinamis seperti checkout, login, dan pencarian produk.
Apa yang terjadi jika semua PHP worker sedang sibuk?
Request dinamis baru menunggu dalam antrean server sampai ada worker bebas. Bila waktu tunggu melewati batas timeout, browser menampilkan error 504 Gateway Timeout meski CPU terlihat longgar.
Apakah menaikkan memory limit PHP otomatis menambah worker?
Tidak. Memory limit mengatur batas RAM maksimal untuk satu proses, bukan jumlah proses yang berjalan. Menambah worker diatur lewat pm.max_children sesuai RAM fisik yang tersedia.
Butuh bantuan menghitung worker untuk tokomu? Hubungi WhatsApp Mordenhost atau portal tiket untuk pemetaan kebutuhan.
