Versi artikel yang belum diedit pada awalnya diterbitkan di haydenjames.io dan diterbitkan di sini dengan izin dari penulisnya .
Singkatnya, saya akan berbicara tentang cara terbaik mengkonfigurasi PHP-FPM untuk meningkatkan throughput, mengurangi latensi dan penggunaan sumber daya prosesor dan memori yang lebih stabil. Secara default, string PM (proses manager) di PHP-FPM adalah dinamis , dan jika Anda tidak memiliki cukup memori, lebih baik untuk menginstal permintaan . Mari kita bandingkan 2 opsi kontrol berdasarkan pada dokumentasi php.net dan lihat bagaimana pm statis favorit saya berbeda dari mereka untuk sejumlah besar lalu lintas:
pm = dinamis - jumlah proses anak dikonfigurasikan secara dinamis berdasarkan arahan berikut: pm.max_children, pm.start_servers, pm.min_spare_servers, pm.max_spare_servers .
pm = ondemand - proses dibuat sesuai permintaan (tidak seperti pembuatan dinamis, ketika pm.start_servers dimulai ketika layanan dimulai).
pm = statis - jumlah proses anak diperbaiki dan ditentukan oleh parameter pm.max_children .
Lihat daftar lengkap arahan global php-fpm.conf untuk detailnya .
Kesamaan dari manajer proses PHP-FPM dengan pengontrol frekuensi prosesor
Ini mungkin terlihat offtopic, tapi saya akan menghubungkan ini dengan topik konfigurasi PHP-FPM. Siapa pun yang setidaknya sekali tidak memperlambat prosesor - pada laptop, mesin virtual atau server khusus. Ingat penskalaan frekuensi prosesor? Opsi ini, tersedia untuk nix dan Windows, dapat meningkatkan kinerja dan respons sistem dengan mengubah pengaturan pengontrol prosesor dari ondemand ke kinerja *. Kali ini, mari kita bandingkan deskripsi dan lihat persamaannya:
Governor = ondemand - penskalaan dinamis dari frekuensi prosesor tergantung pada beban saat ini. Beralih dengan tajam ke frekuensi maksimum, dan kemudian menguranginya saat periode idle meningkat.
Governor = konservatif = penskalaan frekuensi dinamis tergantung pada beban saat ini. Menambah dan mengurangi frekuensi lebih lancar daripada permintaan.
Governor = kinerja - frekuensinya selalu maksimum.
Lihat daftar lengkap parameter pengontrol frekuensi prosesor untuk detailnya.
Lihat kemiripannya? Saya ingin menunjukkan perbandingan ini untuk meyakinkan Anda bahwa yang terbaik adalah menggunakan pm static untuk PHP-FPM.
Untuk pengontrol prosesor, parameter kinerja membantu meningkatkan kinerja dengan aman karena hampir seluruhnya bergantung pada batas prosesor server. Selain itu, tentu saja, ada juga faktor-faktor seperti suhu, muatan baterai (dalam laptop) dan efek samping lain dari operasi prosesor yang konstan sebesar 100%. Penyelarasan kinerja memberikan kinerja prosesor tercepat. Baca, misalnya, tentang parameter force_turbo di Raspberry Pi , yang dengannya panel RPi akan menggunakan kontrol kinerja , di mana peningkatan kinerja akan lebih terlihat karena kecepatan clock CPU yang rendah.
Menggunakan pm static untuk memaksimalkan kinerja server
Parameter statis PHP-FPM pm sebagian besar tergantung pada kehabisan memori pada server. Jika memori rendah, lebih baik untuk memilih permintaan atau dinamis . Di sisi lain, jika Anda memiliki memori, Anda dapat menghindari overhead manajer proses PHP dengan menetapkan pm statis ke kapasitas server maksimum. Dengan kata lain, jika semuanya dihitung dengan baik, Anda harus menetapkan pm.static ke jumlah maksimum proses PHP-FPM yang dapat dieksekusi tanpa membuat masalah dengan memori atau cache yang tidak mencukupi. Tetapi tidak terlalu tinggi untuk membebani prosesor dan mengumpulkan banyak operasi PHP-FPM yang menunggu eksekusi .
Pada tangkapan layar di atas, server memiliki pm = statis dan pm.max_children = 100 diinstal, dan ini membutuhkan sekitar 10 GB dari 32 yang tersedia. Perhatikan kolom yang disorot, semuanya jelas di sini. Dalam tangkapan layar ini, ada sekitar 200 pengguna aktif (lebih dari 60 detik) di Google Analytics. Pada tingkat ini, sekitar 70% dari proses anak PHP-FPM masih menganggur. Ini berarti bahwa PHP-FPM selalu diatur ke jumlah maksimum sumber daya server, terlepas dari lalu lintas saat ini. Proses siaga menunggu puncak lalu lintas dan merespons secara instan. Anda tidak harus menunggu pm untuk membuat proses anak dan kemudian menghentikannya ketika periode pm.process_idle_timeout berakhir . Saya menetapkan nilai yang sangat tinggi untuk pm.max_requests , karena ini adalah server yang berfungsi tanpa kebocoran memori di PHP. Anda dapat menetapkan pm.max_requests = 0 dengan statis jika Anda benar-benar yakin dengan skrip PHP yang ada dan yang akan datang. Tetapi lebih baik untuk me-restart skrip dari waktu ke waktu. Instal sejumlah besar kueri, karena kami ingin menghindari overhead yang tidak perlu dari pm. Misalnya, setidaknya pm.max_requests = 1000 - tergantung pada jumlah pm.max_children dan jumlah permintaan per detik.
Tangkapan layar memperlihatkan perintah top Linux , difilter oleh u (pengguna) dan nama pengguna PHP-FPM. Hanya 50 atau lebih proses pertama yang diperlihatkan (saya tidak menghitung dengan tepat), tetapi, pada kenyataannya, atas menunjukkan statistik teratas yang ditempatkan di jendela terminal. Dalam hal ini, diurutkan berdasarkan% CPU (% CPU). Untuk melihat semua 100 proses PHP-FPM, jalankan perintah:
top -bn1 | grep php-fpm
Kapan harus menggunakan pm ondemand dan dinamis
Jika Anda menggunakan pm dynamic , Anda mendapatkan kesalahan serupa:
WARNING: [pool xxxx] seems busy (you may need to increase pm.start_servers, or pm.min/max_spare_servers), spawning 32 children, there are 4 idle, and 59 total children
Coba ubah parameternya, kesalahan tidak akan kemana-mana, seperti yang dijelaskan dalam posting ini di Serverfault . Dalam hal ini, nilai pm.min terlalu kecil, dan karena lalu lintas web banyak berubah dan memiliki puncak tinggi dan tetesan dalam, sulit untuk mengkonfigurasi pm dinamis secara memadai. Ini biasanya menggunakan pm ondemand , seperti yang disarankan dalam posting yang sama . Tetapi ini bahkan lebih buruk, karena permintaan mengakhiri proses idle ke nol ketika ada sedikit atau tidak ada lalu lintas sama sekali, dan sebagai hasilnya, Anda masih akan menderita biaya ketika lalu lintas berubah. Kecuali, tentu saja, Anda telah menetapkan waktu tunggu yang sangat besar. Dan kemudian lebih baik menggunakan pm.static + sejumlah besar pm.max_requests .
PM dinamis dan terutama permintaan dapat berguna jika Anda memiliki beberapa kumpulan PHP-FPM. Misalnya, Anda meng-host beberapa akun cPanel atau beberapa situs web di kumpulan yang berbeda. Saya memiliki server di mana, misalnya, 100+ akun cpanel dan sekitar 200 domain, dan pm.static atau bahkan dinamis tidak akan menyelamatkan saya. Hanya ondemand yang diperlukan di sini, karena lebih dari dua pertiga situs web menerima sedikit atau tidak ada traffic sama sekali, dan dengan ondemand semua proses anak-anak akan jatuh, yang akan menghemat banyak memori! Untungnya, pengembang cPanel memperhatikan hal ini dan menetapkan nilai default ke permintaan . Sebelumnya, ketika nilai default adalah dinamis , PHP-FPM sama sekali tidak cocok untuk server bersama yang sibuk. Banyak yang menggunakan suPHP karena pm dynamic mengkonsumsi memori bahkan dengan kolam idle dan akun cPanel PHP-FPM. Kemungkinan besar, dengan lalu lintas yang baik, Anda tidak akan di-host di server dengan sejumlah besar kumpulan PHP-FPM (shared hosting).
Kesimpulan
Jika Anda menggunakan PHP-FPM dan Anda memiliki lalu lintas yang padat, ondemand dan manajer proses dinamis untuk PHP-FPM akan membatasi bandwidth karena biaya yang melekat. Periksa sistem Anda dan konfigurasikan proses PHP-FPM Anda agar sesuai dengan kapasitas server maksimum Anda. Pertama-tama atur pm.max_children tergantung pada penggunaan maksimum pm dynamic atau ondemand , dan kemudian tingkatkan nilai ini ke tingkat di mana memori dan prosesor akan bekerja tanpa kelebihan beban yang berlebihan. Anda akan melihat bahwa dengan pm statis , karena semuanya disimpan dalam memori, lalu lintas puncak dari waktu ke waktu akan menyebabkan lebih sedikit puncak untuk prosesor, dan rata-rata server dan nilai beban prosesor akan menyamakan. Ukuran proses PHP-FPM rata-rata tergantung pada server web dan membutuhkan konfigurasi manual, sehingga manajer proses yang lebih otomatis - dinamis dan ondemand - lebih populer. Semoga artikel ini bermanfaat.
UPD Menambahkan diagram benchmark ab . Jika proses PHP-FPM dalam memori, kinerja ditingkatkan dengan mengkonsumsi memori tempat mereka duduk dan menunggu. Temukan opsi terbaik untuk diri Anda sendiri.
