Mengoptimalkan PHP-FPM untuk Kinerja Tinggi

PHP ada di mana-mana dan bisa dibilang bahasa yang paling banyak digunakan di Internet Web.


Namun, itu tidak dikenal karena kemampuan kinerja tinggi, terutama ketika datang ke sistem yang sangat bersamaan. Dan itulah alasan mengapa untuk kasus penggunaan khusus seperti itu, bahasa seperti Node (ya, saya tahu, itu bukan bahasa), Go dan Elixir mengambil alih.

Yang mengatakan, ada BANYAK yang dapat Anda lakukan untuk meningkatkan kinerja PHP di server Anda. Artikel ini berfokus pada sisi php-fpm, yang merupakan cara alami untuk mengonfigurasi di server Anda jika Anda menggunakan Nginx.

Jika Anda tahu apa itu php-fpm, silakan lompat ke bagian tentang optimasi.

Apa itu php-fpm?

Tidak banyak pengembang tertarik pada DevOps sisi hal, dan bahkan di antara mereka yang melakukannya, sangat sedikit yang tahu apa yang terjadi di bawah tenda. Yang menarik, ketika browser mengirim permintaan ke server yang menjalankan PHP, bukan PHP yang menjadi titik kontak pertama; alih-alih, ini adalah server HTTP, yang utamanya adalah Apache dan Nginx. Ini “server web” kemudian harus memutuskan bagaimana menghubungkan ke PHP, dan meneruskan jenis permintaan, data, dan header ke sana.

Siklus permintaan-respons dalam kasus PHP (Kredit gambar: ProinerTech)

Dalam aplikasi PHP modern, bagian “find file” di atas adalah index.php, yang dikonfigurasi oleh server untuk mendelegasikan semua permintaan ke.

Sekarang, bagaimana sebenarnya server web terhubung ke PHP telah berevolusi, dan artikel ini akan meledak panjang jika kita ingin masuk ke semua seluk-beluk. Tetapi secara kasar, selama waktu Apache mendominasi sebagai server web pilihan, PHP adalah modul yang disertakan di dalam server.

Jadi, setiap kali permintaan diterima, server akan memulai proses baru, yang secara otomatis akan menyertakan PHP, dan menyelesaikannya. Metode ini disebut mod_php, singkatan dari “php as a module.” Pendekatan ini memiliki keterbatasan, yang mengatasi Nginx dengan php-fpm.

Dalam php-fpm tanggung jawab mengelola PHP, proses terletak pada program PHP di dalam server. Dengan kata lain, server web (Nginx, dalam kasus kami), tidak peduli di mana PHP berada dan bagaimana PHP dimuat, selama ia tahu cara mengirim dan menerima data darinya. Jika Anda mau, Anda dapat menganggap PHP dalam hal ini sebagai server lain, yang mengelola beberapa proses PHP turunan untuk permintaan masuk (jadi, kami memiliki permintaan menjangkau server, yang diterima oleh server dan diteruskan ke server – Cukup gila! :-P).

Jika Anda telah melakukan pengaturan Nginx apa pun, atau bahkan sekadar membukanya, Anda akan menemukan sesuatu seperti ini:

lokasi ~ \ .php $ {
try_files $ uri = 404;
fastcgi_split_path_info ^ (. + \. php) (/.+) $;
fastcgi_pass unix: /run/php/php7.2-fpm.sock;
fastcgi_index index.php;
termasuk fastcgi_params;
fastcgi_param SCRIPT_FILENAME $ document_root $ fastcgi_script_name;
}

Baris yang kami minati adalah ini: fastcgi_pass unix: /run/php/php7.2-fpm.sock ;, yang memberitahu Nginx untuk berkomunikasi dengan proses PHP melalui soket bernama php7.2-fpm.sock. Jadi, untuk setiap permintaan yang masuk, Nginx menulis data melalui file ini, dan saat menerima output, mengirimkannya kembali ke browser.

Sekali lagi, saya harus menekankan bahwa ini bukan gambaran yang paling lengkap atau paling akurat tentang apa yang terjadi, tetapi ini sepenuhnya akurat untuk sebagian besar tugas DevOps.

Dengan mengesampingkan itu, mari rekap apa yang telah kita pelajari sejauh ini:

  • PHP tidak secara langsung menerima permintaan yang dikirim oleh browser. Server web seperti Nginx pertama kali mencegat ini.
  • Server web tahu bagaimana menghubungkan ke proses PHP, dan meneruskan semua data permintaan (secara harfiah menempel semuanya) ke PHP.
  • Ketika PHP selesai melakukan bagiannya, ia mengirimkan respons kembali ke server web, yang mengirimkannya kembali ke klien (atau browser, dalam kebanyakan kasus).

Atau secara grafis:

Bagaimana PHP dan Nginx bekerja bersama (Kredit gambar: DataDog)

Sejauh ini hebat, tapi sekarang muncul pertanyaan jutaan dolar: apa sebenarnya PHP-FPM?

Bagian “FPM” dalam PHP adalah singkatan dari “Fast Process Manager”, yang hanya cara mewah untuk mengatakan bahwa PHP yang berjalan di server bukan proses tunggal, melainkan beberapa proses PHP yang muncul, dikontrol, dan dibunuh off oleh manajer proses FPM ini. Ini adalah pengelola proses yang dilewati oleh server web.

PHP-FPM adalah seluruh lubang kelinci itu sendiri, jadi silakan menjelajahi jika Anda mau, tetapi untuk tujuan kami, banyak penjelasan ini akan dilakukan. ��

Mengapa mengoptimalkan php-fpm?

Jadi mengapa khawatir tentang semua tarian ini ketika semuanya baik-baik saja? Mengapa tidak meninggalkan saja apa adanya.

Ironisnya, itulah saran yang saya berikan untuk sebagian besar kasus penggunaan. Jika pengaturan Anda berfungsi dengan baik dan tidak memiliki kasus penggunaan yang luar biasa, gunakan default. Namun, jika Anda ingin meningkatkan skala di luar satu mesin, maka memeras maks dari satu sangat penting karena dapat mengurangi tagihan server menjadi dua (atau bahkan lebih!).

Hal lain yang perlu disadari adalah bahwa Nginx dibangun untuk menangani beban kerja yang sangat besar. Ini mampu menangani ribuan koneksi pada saat yang sama, tetapi jika hal yang sama tidak berlaku untuk pengaturan PHP Anda, Anda hanya akan membuang-buang sumber daya karena Nginx harus menunggu PHP selesai dengan proses saat ini dan menerima selanjutnya, secara meyakinkan negatif setiap keuntungan yang Nginx dibangun untuk memberikan!

Jadi, dengan itu, mari kita lihat apa yang sebenarnya kita ubah ketika mencoba mengoptimalkan php-fpm.

Cara mengoptimalkan PHP-FPM?

Lokasi file konfigurasi untuk php-fpm mungkin berbeda di server, jadi Anda perlu melakukan riset untuk menemukannya. Anda dapat menggunakan perintah find jika di UNIX. Di Ubuntu saya, jalannya adalah /etc/php/7.2/fpm/php-fpm.conf. 7.2, tentu saja, versi PHP yang saya jalankan.

Berikut ini beberapa baris pertama file ini:

;;;;;;;;;;;;;;;;;;;;;
; Konfigurasi FPM;
;;;;;;;;;;;;;;;;;;;;;

; Semua jalur relatif dalam file konfigurasi ini relatif terhadap pemasangan PHP
; awalan (/ usr). Awalan ini dapat diubah secara dinamis dengan menggunakan
; Argumen ‘-p’ dari baris perintah.

;;;;;;;;;;;;;;;;;;;
; Opsi Global;
;;;;;;;;;;;;;;;;;;;

[global]
; File id
; Catatan: awalan default adalah / var
; Nilai Default: tidak ada
pid = /run/php/php7.2-fpm.pid

; File log kesalahan
; Jika diatur ke "syslog", log dikirim ke syslogd alih-alih ditulis
; ke dalam file lokal.
; Catatan: awalan default adalah / var
; Nilai Default: log / php-fpm.log
error_log = /var/log/php7.2-fpm.log

Beberapa hal harus segera jelas: baris pid = /run/php/php7.2-fpm.pid memberitahu kita file mana yang berisi id proses dari proses php-fpm.

Kita juga melihat bahwa /var/log/php7.2-fpm.log adalah tempat php-fpm akan menyimpan log-nya.

Di dalam file ini, tambahkan tiga variabel lagi seperti ini:

emergency_restart_threshold 10
emergency_restart_interval 1m
process_control_timeout 10s

Dua pengaturan pertama adalah peringatan dan memberitahu proses php-fpm bahwa jika sepuluh proses anak gagal dalam satu menit, proses php-fpm utama harus restart sendiri.

Ini mungkin kedengarannya tidak kuat, tetapi PHP adalah proses jangka pendek yang tidak bocor memori, jadi memulai kembali proses utama dalam kasus kegagalan tinggi dapat memecahkan banyak masalah.

Opsi ketiga, process_control_timeout, memberi tahu anak proses untuk menunggu sebanyak ini sebelum mengeksekusi sinyal yang diterima dari proses induk. Ini berguna dalam kasus-kasus di mana proses anak berada di tengah-tengah sesuatu ketika orangtua memproses mengirim sinyal KILL, misalnya. Dengan sepuluh detik, mereka akan memiliki peluang lebih baik untuk menyelesaikan tugas dan keluar dengan anggun.

Anehnya, ini bukan daging konfigurasi php-fpm! Itu karena untuk melayani permintaan web, php-fpm membuat kumpulan proses baru, yang akan memiliki konfigurasi terpisah. Dalam kasus saya, nama kumpulan ternyata adalah www dan file yang ingin saya edit adalah /etc/php/7.2/fpm/pool.d/www.conf.

Mari kita lihat seperti apa file ini dimulai:

; Mulai kumpulan baru bernama ‘www’.
; variabel $ pool dapat digunakan dalam arahan apa pun dan akan diganti oleh
; nama kolam (‘www’ di sini)
[www]

; Awalan per kumpulan
; Ini hanya berlaku pada arahan berikut:
; – ‘access.log’
; – ‘slowlog’
; – ‘dengarkan’ (unixsocket)
; – ‘chroot’
; – ‘chdir’
; – ‘php_values’
; – ‘php_admin_values’
; Ketika tidak disetel, awalan global (atau / usr) berlaku sebagai gantinya.
; Catatan: Arahan ini juga bisa relatif terhadap awalan global.
; Nilai Default: tidak ada
; awalan = / path / ke / pools / $ pool

; Unix pengguna / grup proses
; Catatan: Pengguna wajib. Jika grup tidak disetel, grup pengguna default
; akan digunakan.
pengguna = www-data
group = www-data

Pandangan cepat pada akhir cuplikan di atas memecahkan teka-teki mengapa proses server berjalan sebagai www-data. Jika Anda menemukan masalah izin file saat menyiapkan situs web Anda, Anda kemungkinan besar mengubah pemilik atau grup direktori menjadi www-data, sehingga memungkinkan proses PHP untuk dapat menulis ke file log dan mengunggah dokumen, dll..

Akhirnya, kami tiba di sumber masalah, pengaturan manajer proses (pm). Secara umum, Anda akan melihat default sebagai sesuatu seperti ini:

pm = dinamis
pm.max_children = 5
pm.start_servers = 3
pm.min_spare_servers = 2
pm.max_spare_servers = 4
pm.max_requests = 200

Jadi, apa artinya “dinamis“Di sini berarti? Saya pikir dokumen resmi paling baik menjelaskan hal ini (maksud saya, ini seharusnya sudah menjadi bagian dari file yang sedang Anda edit, tetapi saya telah memperbanyaknya di sini kalau-kalau tidak):

; Pilih bagaimana manajer proses akan mengontrol jumlah proses anak.
; Nilai yang Mungkin:
; statis – nomor tetap (pm.max_children) dari proses anak;
; dinamis – jumlah proses anak diatur secara dinamis berdasarkan
; mengikuti arahan. Dengan manajemen proses ini, akan ada
; selalu setidaknya 1 anak.
; pm.max_children – jumlah maksimum anak yang bisa
; tetap hidup pada saat yang sama.
; pm.start_servers – jumlah anak yang dibuat saat startup.
; pm.min_spare_servers – jumlah minimum anak di ‘idle’
; negara (menunggu proses). Jika angkanya
; proses ‘idle’ kurang dari ini
; nomor maka beberapa anak akan dibuat.
; pm.max_spare_servers – jumlah maksimum anak di ‘idle’
; negara (menunggu proses). Jika angkanya
; proses ‘idle’ lebih besar dari ini
; Jumlah maka beberapa anak akan terbunuh.
; ondemand – tidak ada anak yang dibuat saat startup. Anak-anak akan bercabang kapan
; permintaan baru akan terhubung. Parameter berikut digunakan:
; pm.max_children – jumlah maksimum anak itu
; bisa hidup pada saat bersamaan.
; pm.process_idle_timeout – Jumlah detik setelahnya
; proses idle akan terbunuh.
; Catatan: Nilai ini wajib.

Jadi, kita melihat bahwa ada tiga nilai yang mungkin:

  • Statis: Sejumlah proses PHP tetap akan dipertahankan apa pun yang terjadi.
  • Dinamis: Kita harus menentukan minimum dan jumlah maksimum proses yang php-fpm akan tetap hidup pada titik waktu tertentu.
  • ondemand: Proses dibuat dan dihancurkan, baik, sesuai permintaan.

Jadi, bagaimana pengaturan ini penting?

Dalam istilah sederhana, jika Anda memiliki situs web dengan lalu lintas rendah, pengaturan “dinamis” adalah pemborosan sumber daya sepanjang waktu. Dengan asumsi bahwa Anda memiliki pm.min_spare_servers diatur ke 3, tiga proses PHP akan dibuat dan dikelola bahkan ketika tidak ada lalu lintas di situs web. Dalam kasus seperti itu, “ondemand” adalah pilihan yang lebih baik, membiarkan sistem memutuskan kapan akan meluncurkan proses baru.

Di sisi lain, situs web yang menangani lalu lintas dalam jumlah besar atau harus merespons dengan cepat akan dihukum dalam pengaturan ini. Membuat proses PHP baru, menjadikannya bagian dari kumpulan, dan memonitornya, merupakan biaya tambahan yang sebaiknya dihindari.

Menggunakan pm = statis memperbaiki jumlah proses anak, membiarkan sumber daya sistem maksimum untuk digunakan dalam melayani permintaan daripada mengelola PHP. Jika Anda memilih rute ini, berhati-hatilah karena ia memiliki panduan dan perangkapnya. Artikel yang agak padat tapi sangat bermanfaat tentang itu sini.

Kata-kata terakhir

Karena artikel tentang kinerja web dapat memicu perang atau membuat orang bingung, saya merasa ada beberapa kata yang harus diucapkan sebelum kita menutup artikel ini. Penyelarasan kinerja adalah tentang menebak dan ilmu hitam seperti halnya pengetahuan sistem.

Bahkan jika Anda tahu semua pengaturan php-fpm dengan hati, kesuksesan tidak dijamin. Jika Anda tidak memiliki petunjuk tentang keberadaan php-fpm, maka Anda tidak perlu membuang waktu untuk mengkhawatirkannya. Terus lakukan apa yang sudah Anda lakukan dan teruskan.

Pada saat yang sama, hindari akhir menjadi pecandu kinerja. Ya, Anda bisa mendapatkan kinerja yang lebih baik dengan mengkompilasi ulang PHP dari awal dan menghapus semua modul yang tidak akan Anda gunakan, tetapi pendekatan ini tidak cukup waras di lingkungan produksi. Seluruh gagasan untuk mengoptimalkan sesuatu adalah dengan melihat apakah kebutuhan Anda berbeda dari standar (yang jarang mereka lakukan!), Dan buat perubahan kecil sesuai kebutuhan.

Jika Anda tidak siap untuk menghabiskan waktu untuk mengoptimalkan server PHP Anda, maka Anda dapat mempertimbangkan memanfaatkan platform yang dapat diandalkan seperti Kinsta yang menjaga optimasi dan keamanan kinerja.

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map