PHP-FPM quraşdırma: maksimum performans üçün pm statik istifadə edin

Bu məqalənin redaktə edilməmiş variantı ilkin olaraq saytında dərc edilmişdir haydenjames.io və onun icazəsi ilə burada dərc edilmişdir müəllif.

PHP-FPM-ni ötürmə qabiliyyətini artırmaq, gecikməni azaltmaq və CPU və yaddaşdan daha ardıcıl istifadə etmək üçün ən yaxşı şəkildə necə konfiqurasiya edəcəyinizi qısaca izah edəcəyəm. Varsayılan olaraq, PHP-FPM-də PM (proses meneceri) xəttidir dinamik, və kifayət qədər yaddaşınız yoxdursa, quraşdırmaq daha yaxşıdır tələb. Gəlin php.net sənədlərinə əsaslanan 2 nəzarət variantını müqayisə edək və mənim sevimlilərimin onlardan nə ilə fərqləndiyini görək. statik yüksək trafik üçün pm:

pm = dinamik — uşaq proseslərin sayı aşağıdakı direktivlərə əsasən dinamik şəkildə konfiqurasiya edilir: pm.max_uşaqlar, pm.start_servers, pm.min_spare_servers, pm.max_spare_servers.
pm = tələb - proseslər tələb əsasında yaradılır (dinamik yaratmadan fərqli olaraq, xidmət başlayanda pm.start_servers işə salındıqda).
pm = statik — uşaq proseslərin sayı sabitdir və parametrlə göstərilir pm.max_uşaqlar.

Ətraflı məlumat üçün bax php-fpm.conf qlobal direktivlərinin tam siyahısı.

PHP-FPM proses meneceri və CPU tezliyi nəzarətçisi arasındakı oxşarlıqlar

Bu mövzudan kənar görünə bilər, lakin mən bunu PHP-FPM konfiqurasiyası mövzusu ilə əlaqələndirəcəyəm. Ən azı bir dəfə - noutbukda, virtual maşında və ya xüsusi serverdə prosessorun yavaşlaması ilə kim qarşılaşmayıb? CPU tezliyinin miqyasını xatırlayırsınız? Bu seçimlər üçün mövcuddur nix və Windows, prosessorun tənzimləmə parametrini dəyişdirərək sistemin performansını və cavab reaksiyasını yaxşılaşdıra bilər tələb haqqında performans*. Bu dəfə təsvirləri müqayisə edib oxşar cəhətlərə baxaq:

qubernator=tələb — cari yükdən asılı olaraq prosessor tezliyinin dinamik miqyası. Sürətlə maksimum tezlikə sıçrayır və sonra hərəkətsizlik dövrləri artdıqca onu azaldır.
qubernator=mühafizəkar= cari yükdən asılı olaraq dinamik tezlik miqyası. Tezliyi tələbdən daha rəvan artırır və azaldır.
Qubernator = performans — tezlik həmişə maksimumdur.

Ətraflı məlumat üçün bax prosessor tezlik tənzimləyicisi parametrlərinin tam siyahısı.

Bənzərliklərə baxın? İstifadə etməyin ən yaxşısı olduğuna inandırmaq üçün bu müqayisəni göstərmək istədim pm statik PHP-FPM üçün.

Prosessor tənzimləyicisi parametri üçün icra performansı təhlükəsiz şəkildə artırmağa kömək edir, çünki o, demək olar ki, tamamilə serverin CPU limitindən asılıdır. Bundan əlavə, təbii ki, prosessorun daim 100% işləməsinin temperatur, batareyanın doldurulması (noutbukda) və digər yan təsirləri kimi amillər də var. Performans parametri prosessorun ən sürətli performansını təmin edir. Məsələn, haqqında oxuyun Raspberry Pi-də force_turbo parametri, RPi panelinin tənzimləyicidən istifadə edəcəyi icra, burada aşağı CPU saat sürətinə görə performans yaxşılaşması daha nəzərə çarpacaq.

Maksimum server performansına nail olmaq üçün pm statik istifadə

PHP-FPM seçimi pm statik əsasən serverdəki boş yaddaşdan asılıdır. Yaddaş zəifdirsə, seçmək daha yaxşıdır tələb və ya dinamik. Digər tərəfdən, yaddaşınız varsa, pm təyin etməklə PHP proses meneceri yükündən qaça bilərsiniz statik maksimum server tutumuna. Başqa sözlə, hər şey yaxşı hesablanıbsa, qurmaq lazımdır pm.statik icra edilə bilən PHP-FPM proseslərinin maksimum həcminə, aşağı yaddaş və ya keş ilə problem yaratmadan. Lakin o qədər yüksək deyil ki, prosessorları üstələyir və yerinə yetirilməsini gözləyən bir dəstə PHP-FPM əməliyyatı toplayır..

Yuxarıdakı ekran görüntüsündə server var pm = statik və pm.max_children = 100, və bu, mövcud 10 GB-dan təxminən 32 GB yer tutur. Vurğulanmış sütunlara diqqət yetirin, burada hər şey aydındır. Bu ekran görüntüsündə Google Analytics-də təxminən 200 aktiv istifadəçi (60 saniyədən çox) var idi. Bu səviyyədə PHP-FPM uşaq proseslərinin təxminən 70%-i hələ də boşdur. Bu o deməkdir ki, PHP-FPM həmişə cari trafikdən asılı olmayaraq server resurslarının maksimum miqdarına təyin edilir. Boş bir proses trafikin pik nöqtələrini gözləyir və dərhal cavab verir. Sizə qədər gözləmək lazım deyil pm uşaq prosesləri yaradacaq və müddət bitdikdə onları dayandıracaq pm.process_idle_timeout. Mən dəyəri çox yüksək təyin etdim pm.max_istəklərçünki bu, PHP-də yaddaş sızması olmayan işləyən serverdir. Siz quraşdıra bilərsiniz pm.max_requests = 0 mövcud və gələcək PHP skriptlərinə tam əminsinizsə, statik ilə. Ancaq vaxt keçdikcə skriptləri yenidən işə salmaq daha yaxşıdır. Çox sayda sorğu təyin edin, çünki lazımsız pm xərclərinin qarşısını almaq istəyirik. Məsələn, heç olmasa pm.max_requests = 1000 - kəmiyyətdən asılı olaraq pm.max_uşaqlar və saniyədə sorğuların sayı.

Ekran görüntüsü əmri göstərir Linux üstü, u (istifadəçi) və PHP-FPM istifadəçi adı ilə süzülür. Yalnız ilk 50-yə yaxın proses göstərilir (dəqiq saymadım), lakin mahiyyətcə yuxarıda terminal pəncərəsinə uyğun gələn ən yaxşı statistika göstərilir. Bu halda% CPU (%CPU) ilə sıralanır. Bütün 100 PHP-FPM prosesini görmək üçün əmri işlədin:

top -bn1 | grep php-fpm

Pm-dən nə vaxt istifadə etməli və dinamik

pm istifadə etsəniz dinamik, bu kimi xətalar baş verir:

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

Parametri dəyişdirməyə çalışın, səhv getməyəcək, məsələn Serverfault haqqında bu yazıda təsvir edilmişdir. Bu halda, pm.min dəyəri çox kiçik idi və veb trafik çox dəyişdiyinə və yüksək zirvələrə və dərin vadilərə malik olduğundan, pm-ni adekvat şəkildə tənzimləmək çətindir. dinamik. Adətən pm istifadə olunur tələb, eyni yazıda tövsiyə edildiyi kimi. Ancaq bu daha da pisdir, çünki tələb az və ya heç trafik olmadığı zaman boş prosesləri sıfıra endirir və siz yenə də trafikin dəyişdirilməsi ilə bağlı yüklə başa çatacaqsınız. Əlbəttə ki, böyük bir gözləmə müddəti təyin etməsəniz. Və sonra istifadə etmək daha yaxşıdır pm.statik + yüksək rəqəm pm.max_istəklər.

PM dinamik və xüsusilə də tələb çoxlu PHP-FPM hovuzunuz varsa, faydalı ola bilər. Məsələn, müxtəlif hovuzlarda birdən çox cPanel hesabı və ya birdən çox veb saytı yerləşdirirsiniz. Mənim məsələn, 100+ cpanel hesabı və təxminən 200 domeni olan bir serverim var və pm.static və ya hətta dinamik məni xilas etməyəcək. Burada sizə lazım olan tək şey budur tələb, nəhayət, veb saytların üçdə ikisindən çoxu az və ya heç trafik almır və bununla da tələb bütün uşaq prosesləri yıxılacaq, bu da bizə çox yaddaş saxlayacaq! Xoşbəxtlikdən, cPanel tərtibatçıları bunu fərq etdilər və dəyəri standart olaraq təyin etdilər tələb. Əvvəllər, defolt olanda dinamik, PHP-FPM məşğul paylaşılan serverlər üçün ümumiyyətlə uyğun deyildi. Çoxları istifadə edib suPHP, çünki pm dinamik boş hovuzlar və cPanel PHP-FPM hesabları ilə belə yaddaş istehlak edir. Çox güman ki, trafik yaxşı olarsa, siz çoxlu sayda PHP-FPM hovuzu (paylaşılan hostinq) olan serverdə yerləşdirilməyəcəksiniz.

Nəticə

Əgər PHP-FPM-dən istifadə edirsinizsə və trafikiniz ağırdırsa, menecerləri işə salın tələb и dinamik PHP-FPM üçün onların xas əlavə xərclərinə görə məhdud ötürmə qabiliyyəti olacaq. Sisteminizi anlayın və maksimum server tutumuna uyğun olaraq PHP-FPM proseslərini konfiqurasiya edin. İlk dəst pm.max_uşaqlar maksimum pm istifadəsindən asılı olaraq dinamik və ya tələb, və sonra bu dəyəri yaddaş və prosessorun həddindən artıq yüklənmədən işləyəcəyi səviyyəyə qədər artırın. ilə bunu fərq edəcəksiniz pm statik, yaddaşınızda hər şey olduğundan, trafik sıçrayışları zamanla daha az CPU sıçrayışlarına səbəb olacaq və server və CPU yükləmə ortalamaları bərabərləşəcək. Orta PHP-FPM prosesinin ölçüsü veb serverdən asılıdır və əl ilə konfiqurasiya tələb edir, ona görə də daha avtomatlaşdırılmış proses menecerləri dinamik и tələb - daha məşhur. Ümid edirəm məqalə faydalı oldu.

DUP Benchmark diaqramı əlavə edildi ab. Əgər PHP-FPM prosesləri yaddaşdadırsa, onların oturub gözlədiyi yerdə performans yaddaş sərfi hesabına artır. Özünüz üçün ən yaxşı variantı tapın.

Mənbə: www.habr.com