27.1 C
Jakarta
Senin, 10 Maret 2025

Mengoptimalkan PHP-FPM untuk Performa Tinggi

PHP bisa dibilang bahasa yang paling banyak digunakan di Web Internet.

Namun, itu tidak dikenal karena kemampuannya yang berkinerja 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, ini 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 server Anda jika Anda menggunakan Nginx.

Jika Anda tahu apa itu php-fpm, jangan ragu untuk melompat ke bagian pengoptimalan.

Apa itu PHP-fpm?

Tidak banyak pengembang yang tertarik dengan sisi DevOps, dan bahkan di antara mereka yang melakukannya, sangat sedikit yang tahu apa yang terjadi di balik layar. Menariknya, saat browser mengirim permintaan ke server yang menjalankan PHP, bukan PHP yang menjadi titik kontak pertama; sebaliknya, itu adalah server HTTP, yang utamanya adalah Apache dan Nginx. “Server web” ini kemudian harus memutuskan cara terhubung ke PHP, dan meneruskan jenis permintaan, data, dan header ke sana.
php

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

Sekarang, bagaimana tepatnya server web terhubung ke PHP telah berkembang, dan artikel ini akan meledak panjangnya jika kita ingin masuk ke semua seluk beluknya. Namun secara kasar, selama 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 menyertakan PHP, dan menjalankannya. Metode ini disebut mod_php, kependekan dari “PHP as a module.” Pendekatan ini memiliki keterbatasan, yang diatasi 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 memuatnya, asalkan tahu cara mengirim dan menerima data darinya. Jika mau, Anda dapat menganggap PHP dalam hal ini sebagai server lain itu sendiri, yang mengelola beberapa proses PHP anak untuk permintaan yang masuk.

Jika Anda telah melakukan pengaturan Nginx, atau bahkan hanya membongkarnya, Anda akan menemukan sesuatu seperti ini:

location ~ .php$ {
        try_files $uri =404;
        fastcgi_split_path_info ^(.+.php)(/.+)$;
        fastcgi_pass unix:/run/php/php8.0-fpm.sock;
        fastcgi_index index.php;
        include fastcgi_params;
        fastcgi_param  SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }

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

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

Selain 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-tama mencegat ini.
– Server web tahu cara terhubung ke proses PHP, dan meneruskan semua data permintaan (secara harfiah menempelkan semuanya) ke PHP.
– Ketika PHP selesai melakukan bagiannya, ia mengirimkan respons kembali ke server web, yang mengirimkannya kembali ke klien (atau browser, dalam banyak kasus).
php dan nginx

Hebat sejauh ini, tetapi sekarang muncul pertanyaan jutaan dolar: apa sebenarnya PHP-FPM itu?

Bagian “FPM” di PHP adalah singkatan dari “Fast Process Manager”, yang merupakan cara mewah untuk mengatakan bahwa PHP yang berjalan di server bukanlah proses tunggal, melainkan beberapa proses PHP yang dihasilkan, dikontrol, dan dimatikan dimatikan oleh manajer proses FPM ini. Manajer proses inilah yang diteruskan oleh server web permintaan.

PHP-FPM adalah keseluruhan lubang kelinci itu sendiri, jadi jangan ragu untuk menjelajah jika Anda mau, tetapi untuk tujuan kita, penjelasan sebanyak ini sudah cukup.

Baca Juga:  Cara Mengunduh dan Memasang Auto-GPT Langkah demi Langkah

Mengapa mengoptimalkan PHP-fpm?

Jadi mengapa khawatir tentang semua tarian ini ketika semuanya berjalan dengan baik? Mengapa tidak membiarkan hal-hal seperti apa adanya.

Ironisnya, justru itulah saran yang saya berikan untuk sebagian besar kasus penggunaan. Jika penyiapan Anda berfungsi dengan baik dan tidak memiliki kasus penggunaan yang luar biasa, gunakan default. Namun, jika Anda ingin menskalakan lebih dari satu mesin, maka memeras maksimal 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 besar. Itu 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 negatifkan keuntungan apa pun yang disediakan oleh Nginx

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

Bagaimana 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, jalurnya adalah /etc/php/8.0/fpm/php-fpm.conf. adalah versi PHP yang saya jalankan.

Inilah tampilan beberapa baris pertama dari file ini:

;;;;;;;;;;;;;;;;;;;;;
; FPM Configuration ;
;;;;;;;;;;;;;;;;;;;;;

; All relative paths in this configuration file are relative to PHP's install
; prefix (/usr). This prefix can be dynamically changed by using the
; '-p' argument from the command line.

;;;;;;;;;;;;;;;;;;
; Global Options ;
;;;;;;;;;;;;;;;;;;

[global]
; Pid file
; Note: the default prefix is /var
; Default Value: none
pid = /run/php/php8.0-fpm.pid

; Error log file
; If it's set to "syslog", log is sent to syslogd instead of being written
; into a local file.
; Note: the default prefix is /var
; Default Value: log/php-fpm.log
error_log = /var/log/php8.0-fpm.log

Beberapa hal harus segera jelas: baris pid = /run/php/php8.0-fpm.pid memberi tahu kita file mana yang berisi id proses dari proses php-fpm.

Kita juga melihat bahwa /var/log/php8.0-fpm.log adalah tempat php-fpm akan menyimpan lognya.

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

emergency_restart_threshold 10
emergency_restart_interval 1m
process_control_timeout 10s

Dua setelan pertama bersifat peringatan dan memberi tahu proses php-fpm bahwa jika sepuluh proses anak gagal dalam satu menit, proses utama php-fpm harus dimulai ulang sendiri.

Ini mungkin kedengarannya tidak kuat, tetapi PHP adalah proses berumur pendek yang membocorkan memori, jadi memulai ulang proses utama jika terjadi kegagalan tinggi dapat menyelesaikan banyak masalah.

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

Anehnya, ini bukan inti dari 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/8.0/fpm/pool.d/www.conf.

Mari kita lihat seperti apa file ini dimulai:

; Start a new pool named 'www'.
; the variable $pool can be used in any directive and will be replaced by the
; pool name ('www' here)
[www]

; Per pool prefix
; It only applies on the following directives:
; - 'access.log'
; - 'slowlog'
; - 'listen' (unixsocket)
; - 'chroot'
; - 'chdir'
; - 'php_values'
; - 'php_admin_values'
; When not set, the global prefix (or /usr) applies instead.
; Note: This directive can also be relative to the global prefix.
; Default Value: none
;prefix = /path/to/pools/$pool

; Unix user/group of processes
; Note: The user is mandatory. If the group is not set, the default user's group
;       will be used.
user = www-data
group = www-data

Sekilas di 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, kemungkinan besar Anda telah mengubah pemilik atau grup direktori menjadi www-data, sehingga memungkinkan proses PHP untuk dapat menulis ke dalam file log dan mengunggah dokumen, dll. .

Baca Juga:  Konfigurasi PHP-FPM dengan NGINX

Akhirnya, kami sampai pada sumber masalah, pengaturan manajer proses (pm). Umumnya, Anda akan melihat default sebagai sesuatu seperti ini:

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

Jadi, apa yang dimaksud dengan “dynamic” di sini? Menurut saya, 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 bukan):

; Choose how the process manager will control the number of child processes.
; Possible Values:
;   static  - a fixed number (pm.max_children) of child processes;
;   dynamic - the number of child processes are set dynamically based on the
;             following directives. With this process management, there will be
;             always at least 1 children.
;             pm.max_children      - the maximum number of children that can
;                                    be alive at the same time.
;             pm.start_servers     - the number of children created on startup.
;             pm.min_spare_servers - the minimum number of children in 'idle'
;                                    state (waiting to process). If the number
;                                    of 'idle' processes is less than this
;                                    number then some children will be created.
;             pm.max_spare_servers - the maximum number of children in 'idle'
;                                    state (waiting to process). If the number
;                                    of 'idle' processes is greater than this
;                                    number then some children will be killed.
;  ondemand - no children are created at startup. Children will be forked when
;             new requests will connect. The following parameter are used:
;             pm.max_children           - the maximum number of children that
;                                         can be alive at the same time.
;             pm.process_idle_timeout   - The number of seconds after which
;                                         an idle process will be killed.
; Note: This value is mandatory.
pm = dynamic

Jadi, kita melihat bahwa ada tiga kemungkinan nilai:

Static: Sejumlah proses PHP tetap akan dipertahankan apa pun yang terjadi.
Dynamic: Kita dapat menentukan jumlah proses minimum dan maksimum yang akan dipertahankan oleh php-fpm pada titik waktu tertentu.
ondemand: Proses dibuat dan dihancurkan, ya, sesuai permintaan.

Jadi, bagaimana pengaturan ini penting?

Sederhananya, jika Anda memiliki situs web dengan lalu lintas rendah, pengaturan “dynamic” sering kali membuang-buang sumber daya. Dengan asumsi Anda menyetel pm.min_spare_servers = 3, tiga proses PHP akan dibuat dan dikelola bahkan saat tidak ada lalu lintas di situs web. Dalam kasus seperti itu, “ondemand” adalah opsi yang lebih baik, membiarkan sistem memutuskan kapan 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 memantaunya, adalah overhead tambahan yang sebaiknya dihindari.

Menggunakan pm = static memperbaiki jumlah proses tautan, memungkinkan sumber daya sistem maksimum digunakan dalam melayani permintaan daripada mengelola PHP. Jika Anda mengikuti rute ini, berhati-hatilah karena ada pedoman dan jebakannya.

Penjelasan Akhir

Pada saat yang sama, 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 bagus di lingkungan produksi. Seluruh gagasan untuk mengoptimalkan sesuatu adalah untuk melihat apakah kebutuhan Anda berbeda dari default, Dan membuat perubahan kecil sesuai kebutuhan.

Jika Anda tidak siap menghabiskan waktu untuk mengoptimalkan server PHP Anda, maka Anda dapat mempertimbangkan untuk memanfaatkan platform yang andal yang menangani pengoptimalan dan keamanan kinerja.

PHP bisa dibilang bahasa yang paling banyak digunakan di Web Internet.

Namun, itu tidak dikenal karena kemampuannya yang berkinerja 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, ini 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 server Anda jika Anda menggunakan Nginx.

Jika Anda tahu apa itu php-fpm, jangan ragu untuk melompat ke bagian pengoptimalan.

Apa itu PHP-fpm?

Tidak banyak pengembang yang tertarik dengan sisi DevOps, dan bahkan di antara mereka yang melakukannya, sangat sedikit yang tahu apa yang terjadi di balik layar. Menariknya, saat browser mengirim permintaan ke server yang menjalankan PHP, bukan PHP yang menjadi titik kontak pertama; sebaliknya, itu adalah server HTTP, yang utamanya adalah Apache dan Nginx. “Server web” ini kemudian harus memutuskan cara terhubung ke PHP, dan meneruskan jenis permintaan, data, dan header ke sana.
php

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

Sekarang, bagaimana tepatnya server web terhubung ke PHP telah berkembang, dan artikel ini akan meledak panjangnya jika kita ingin masuk ke semua seluk beluknya. Namun secara kasar, selama 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 menyertakan PHP, dan menjalankannya. Metode ini disebut mod_php, kependekan dari “PHP as a module.” Pendekatan ini memiliki keterbatasan, yang diatasi 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 memuatnya, asalkan tahu cara mengirim dan menerima data darinya. Jika mau, Anda dapat menganggap PHP dalam hal ini sebagai server lain itu sendiri, yang mengelola beberapa proses PHP anak untuk permintaan yang masuk.

Jika Anda telah melakukan pengaturan Nginx, atau bahkan hanya membongkarnya, Anda akan menemukan sesuatu seperti ini:

location ~ .php$ {
        try_files $uri =404;
        fastcgi_split_path_info ^(.+.php)(/.+)$;
        fastcgi_pass unix:/run/php/php8.0-fpm.sock;
        fastcgi_index index.php;
        include fastcgi_params;
        fastcgi_param  SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }

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

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

Selain 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-tama mencegat ini.
– Server web tahu cara terhubung ke proses PHP, dan meneruskan semua data permintaan (secara harfiah menempelkan semuanya) ke PHP.
– Ketika PHP selesai melakukan bagiannya, ia mengirimkan respons kembali ke server web, yang mengirimkannya kembali ke klien (atau browser, dalam banyak kasus).
php dan nginx

Hebat sejauh ini, tetapi sekarang muncul pertanyaan jutaan dolar: apa sebenarnya PHP-FPM itu?

Bagian “FPM” di PHP adalah singkatan dari “Fast Process Manager”, yang merupakan cara mewah untuk mengatakan bahwa PHP yang berjalan di server bukanlah proses tunggal, melainkan beberapa proses PHP yang dihasilkan, dikontrol, dan dimatikan dimatikan oleh manajer proses FPM ini. Manajer proses inilah yang diteruskan oleh server web permintaan.

PHP-FPM adalah keseluruhan lubang kelinci itu sendiri, jadi jangan ragu untuk menjelajah jika Anda mau, tetapi untuk tujuan kita, penjelasan sebanyak ini sudah cukup.

Baca Juga:  10 Alasan Mengapa ReactJS Masih Menjadi Pilihan Utama untuk Pengembangan Web Front-End

Mengapa mengoptimalkan PHP-fpm?

Jadi mengapa khawatir tentang semua tarian ini ketika semuanya berjalan dengan baik? Mengapa tidak membiarkan hal-hal seperti apa adanya.

Ironisnya, justru itulah saran yang saya berikan untuk sebagian besar kasus penggunaan. Jika penyiapan Anda berfungsi dengan baik dan tidak memiliki kasus penggunaan yang luar biasa, gunakan default. Namun, jika Anda ingin menskalakan lebih dari satu mesin, maka memeras maksimal 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 besar. Itu 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 negatifkan keuntungan apa pun yang disediakan oleh Nginx

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

Bagaimana 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, jalurnya adalah /etc/php/8.0/fpm/php-fpm.conf. adalah versi PHP yang saya jalankan.

Inilah tampilan beberapa baris pertama dari file ini:

;;;;;;;;;;;;;;;;;;;;;
; FPM Configuration ;
;;;;;;;;;;;;;;;;;;;;;

; All relative paths in this configuration file are relative to PHP's install
; prefix (/usr). This prefix can be dynamically changed by using the
; '-p' argument from the command line.

;;;;;;;;;;;;;;;;;;
; Global Options ;
;;;;;;;;;;;;;;;;;;

[global]
; Pid file
; Note: the default prefix is /var
; Default Value: none
pid = /run/php/php8.0-fpm.pid

; Error log file
; If it's set to "syslog", log is sent to syslogd instead of being written
; into a local file.
; Note: the default prefix is /var
; Default Value: log/php-fpm.log
error_log = /var/log/php8.0-fpm.log

Beberapa hal harus segera jelas: baris pid = /run/php/php8.0-fpm.pid memberi tahu kita file mana yang berisi id proses dari proses php-fpm.

Kita juga melihat bahwa /var/log/php8.0-fpm.log adalah tempat php-fpm akan menyimpan lognya.

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

emergency_restart_threshold 10
emergency_restart_interval 1m
process_control_timeout 10s

Dua setelan pertama bersifat peringatan dan memberi tahu proses php-fpm bahwa jika sepuluh proses anak gagal dalam satu menit, proses utama php-fpm harus dimulai ulang sendiri.

Ini mungkin kedengarannya tidak kuat, tetapi PHP adalah proses berumur pendek yang membocorkan memori, jadi memulai ulang proses utama jika terjadi kegagalan tinggi dapat menyelesaikan banyak masalah.

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

Anehnya, ini bukan inti dari 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/8.0/fpm/pool.d/www.conf.

Mari kita lihat seperti apa file ini dimulai:

; Start a new pool named 'www'.
; the variable $pool can be used in any directive and will be replaced by the
; pool name ('www' here)
[www]

; Per pool prefix
; It only applies on the following directives:
; - 'access.log'
; - 'slowlog'
; - 'listen' (unixsocket)
; - 'chroot'
; - 'chdir'
; - 'php_values'
; - 'php_admin_values'
; When not set, the global prefix (or /usr) applies instead.
; Note: This directive can also be relative to the global prefix.
; Default Value: none
;prefix = /path/to/pools/$pool

; Unix user/group of processes
; Note: The user is mandatory. If the group is not set, the default user's group
;       will be used.
user = www-data
group = www-data

Sekilas di 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, kemungkinan besar Anda telah mengubah pemilik atau grup direktori menjadi www-data, sehingga memungkinkan proses PHP untuk dapat menulis ke dalam file log dan mengunggah dokumen, dll. .

Baca Juga:  Bangun Situs Doc Dengan Next.js Menggunakan Nextra

Akhirnya, kami sampai pada sumber masalah, pengaturan manajer proses (pm). Umumnya, Anda akan melihat default sebagai sesuatu seperti ini:

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

Jadi, apa yang dimaksud dengan “dynamic” di sini? Menurut saya, 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 bukan):

; Choose how the process manager will control the number of child processes.
; Possible Values:
;   static  - a fixed number (pm.max_children) of child processes;
;   dynamic - the number of child processes are set dynamically based on the
;             following directives. With this process management, there will be
;             always at least 1 children.
;             pm.max_children      - the maximum number of children that can
;                                    be alive at the same time.
;             pm.start_servers     - the number of children created on startup.
;             pm.min_spare_servers - the minimum number of children in 'idle'
;                                    state (waiting to process). If the number
;                                    of 'idle' processes is less than this
;                                    number then some children will be created.
;             pm.max_spare_servers - the maximum number of children in 'idle'
;                                    state (waiting to process). If the number
;                                    of 'idle' processes is greater than this
;                                    number then some children will be killed.
;  ondemand - no children are created at startup. Children will be forked when
;             new requests will connect. The following parameter are used:
;             pm.max_children           - the maximum number of children that
;                                         can be alive at the same time.
;             pm.process_idle_timeout   - The number of seconds after which
;                                         an idle process will be killed.
; Note: This value is mandatory.
pm = dynamic

Jadi, kita melihat bahwa ada tiga kemungkinan nilai:

Static: Sejumlah proses PHP tetap akan dipertahankan apa pun yang terjadi.
Dynamic: Kita dapat menentukan jumlah proses minimum dan maksimum yang akan dipertahankan oleh php-fpm pada titik waktu tertentu.
ondemand: Proses dibuat dan dihancurkan, ya, sesuai permintaan.

Jadi, bagaimana pengaturan ini penting?

Sederhananya, jika Anda memiliki situs web dengan lalu lintas rendah, pengaturan “dynamic” sering kali membuang-buang sumber daya. Dengan asumsi Anda menyetel pm.min_spare_servers = 3, tiga proses PHP akan dibuat dan dikelola bahkan saat tidak ada lalu lintas di situs web. Dalam kasus seperti itu, “ondemand” adalah opsi yang lebih baik, membiarkan sistem memutuskan kapan 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 memantaunya, adalah overhead tambahan yang sebaiknya dihindari.

Menggunakan pm = static memperbaiki jumlah proses tautan, memungkinkan sumber daya sistem maksimum digunakan dalam melayani permintaan daripada mengelola PHP. Jika Anda mengikuti rute ini, berhati-hatilah karena ada pedoman dan jebakannya.

Penjelasan Akhir

Pada saat yang sama, 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 bagus di lingkungan produksi. Seluruh gagasan untuk mengoptimalkan sesuatu adalah untuk melihat apakah kebutuhan Anda berbeda dari default, Dan membuat perubahan kecil sesuai kebutuhan.

Jika Anda tidak siap menghabiskan waktu untuk mengoptimalkan server PHP Anda, maka Anda dapat mempertimbangkan untuk memanfaatkan platform yang andal yang menangani pengoptimalan dan keamanan kinerja.

Untuk mendapatkan Berita & Review menarik Saksenengku Network
Google News

Artikel Terkait

Populer

Artikel Terbaru