Adres Bilgilerimiz
Sultançifliği Mah. Bayram Sokak
No: 21/9 Çekmeköy/İstanbul 34788
Müşteri Hizmetleri
M.H: 0850 302 29 99

PHP-FPM ile siteniz nasıl hızlandırılır (FPM conf’umuz var)

Bugün PHP-FPM’yi yapılandırarak bir uygulamanın nasıl hızlandırılacağından bahsetmek istiyorum.

Şimdi bir PHP uygulamasının üzerinde yükseldiği en popüler (karşılaştığım yığınlar) yığını, nginx web sunucusu ve php-fpm işlem yöneticisidir.

Tüm varsayılan seçeneklerle yüklenen bir Laravel projesi ile basit bir uygulamayı barındırmak istiyorum. Basit bir Javascript betiği kullanarak bu uygulamayı kullanıcılarla yüklemeye çalışalım ve yükle nasıl başa çıktığını ve işlenen yükü sadece php-fpm yapılandırarak nasıl artırabileceğimizi görelim. Makalenin sonunda GitHub’a bir bağlantı bulabilir ve kendiniz deneyebilirsiniz.

İlk olarak, varsayılan php-fpm yapılandırmasına bir göz atalım ve performans sorunlarının kutunun dışında nerede olabileceğini anlamaya çalışalım.

Bu nedenle, standart konfigürasyonlarda önceden yüklenmiş NGINX ve PHP-FPM ile basit bir PHP uygulamasına ve bir Laravel rotasına sahibim.

Rota, bir saniyeliğine uyku komutu aracılığıyla yükü simüle eder ve basit bir json yanıtı döndürür.

Ayrıca rotamız için istekte bulunan bir Javascript dosyam var. K6 load yardımcı programını kullanarak çalıştıracağız.

Yük testi yapmak için k6 yardımcı programını beş VU (sanal kullanıcı) ile çalıştıralım.

k6 run –vus 5 –duration 30s script.js

Yükleme sonucu:

Satırda görebileceğiniz gibi http_req_duration avg (tüm göstergeler için ortalama değer) 1,77 saniyedir. Bu, yükün kendisi 1 saniye + isteğin ağdan geçtiği süre ve çerçevenin çalışmasıdır.

Aynısının başka bir testini 10 kullanıcı üzerinde yapalım.

k6 run –vus 10 –duration 30s script.js

Yükleme sonucu:

Gördüğünüz gibi, zaman neredeyse iki katına çıktı.

Bir test daha yapalım ve sorunun ne olduğunu anlayalım.

Bu sefer uygulamamızı tek seferde 50 kullanıcı ile yüklemeye çalışacağız.

k6 run –vus 50 –duration 30s script.js

Yükleme sonucu:

Gördüğünüz gibi, sonuç tamamen üzücü oldu. Ortalama olarak, bir istemci, sunucudan bir yanıt için 15.48 saniye beklemek zorundadır. Sorunun ne olduğunu anlayalım.

İlk olarak, php-fpm konfigürasyonunun ne olduğunu öğrenelim. Bu komut kullanılarak yapılabilirphp-fpm -tt

Bu komut, bir çerçeve ile özetlediğim en önemli parametreler olan tüm php-fpm parametrelerini görüntüleyecektir.

En önemli parametre pm.max_children’dir, şimdi 5’tir. Bu parametre php-fpm’mize kaç tane istek alt işlemi (işleyici) başlatabileceğini söyler. Başka bir deyişle, gelen yükü kaç paralel işlem işleyecektir.

Daha iyi netlik için küçük bir diyagram çizdim.

Uygulamamıza aynı anda 50 müşteri geldiğinde ilk önce NGINX’imiz ile iletişime geçerler, bu sadece bir proxy sunucusudur ve istekleri kendi üzerinden PHP-FPM’ye iletir (statik kaynak/dosya istekleri hariç) ve ardından PHP-FPM hepsini işlemeye çalışır. süreçlerini (işçileri) kullanan istekler. Durum bizimki gibiyse, PHP-FPM’nin sadece beş çalışanı olduğunda, ilk 5 müşteri işlenir ve kalan 45 kişi kuyruğa alınır ve ilk 5’in işlenmesini bekler. İlk 5’i çalışır çalışmaz diğer 5’i yerlerine girmiş ve kalan 40 kişi sırada beklemektedir.

Bu aşamada iki sorun ortaya çıkmaktadır. İlk olarak clientları bu şekilde bir cevap beklemeye zorlarız, ikinci olarak fastcgi_read_timeout parametresinde bekleme süresi NGINX için standarttan yüksekse (standart 30 saniye), sonra NGINX’ten 504 hatası alabiliriz. Bekleme süresini artırarak ikinci sorunu çözebiliriz ama bu bizi birinci sorundan kurtarmaz.

Soruna mantıklı bir çözüm, PHP-FPM için işçi eklemektir ve bu tamamen yeterli bir fikirdir, ancak yeterli sayıda işçi eklemeye özen göstermeli ve tüm işletim belleğini kaplayacak fazladan işçi eklememelisiniz.

Konfigürasyon parametrelerimize geri dönelim ve doğru ayarları yapmaya çalışalım.

Bu nedenle, aşağıdaki parametrelerle ilgileniyoruz:

pm = dynamic – php-fpm çalışan işçi sayısını kendisi kontrol eder, belirtilen parametreyle dinamik php-fpm yüke bağlı olarak işçi ekler veya kaldırır. Ayrıca, bu parametre static değerine sahip olabilir, bu durumda çalışan sayısı statik olacaktır.

pm.max_children – aynı anda çalışan maksimum işlem sayısı. Genellikle bu değer, CPU sayısı için 4 * miktarına konur. CPU sayısını öğrenmek için lscpu komutunu kullanabilirsiniz.

Boş hafıza miktarını kontrol etmek daha doğru olur, bunu şu komutla yapabilirsiniz. free -hl

Bir çalışanın ne kadar bellek aldığını anlamak zorunludur.

Bu, komut kullanılarak yapılabilir htopve php-fpm çalışanları tarafından işgal edilen ortalama bellek miktarını görebilir.

pm.min_spare_servers – Minimum boşta işlem sayısı. Bu miktar, yeni bir müşteri sayısının aniden ortaya çıkması durumunda rezerv olarak gereklidir. İstemcilerin yeni süreçler oluşturulana kadar beklememesi için beklemedeki süreçler ani bir yük alır. Değer genellikle CPU sayısı için 2 * olarak ayarlanır.

pm.max_spare_servers – Boş durumdaki maksimum işlem sayısı. Uygulamada herhangi bir yük yoksa, php-fpm RAM’den tasarruf etmek için gereksiz işlemleri kaldıracaktır.

Tamam, PHP-FPM’mizi yapılandıralım.

İlk olarak, komutu kullanarak yapılandırma dosyasının nerede olduğunu bulalım.

whereis php-fpm

start_server’ı 24 olarak ayarlayın.

min_spare_servers 12’de.

max_spare_servers 24’te.

Docker’ı yeniden başlatın.

Ve 50 kullanıcıyla yük testini tekrar edelim.

Yükleme sonucu:

Gördüğünüz gibi, yükleme sonucu ortalama 1,6 saniyedir. Beş kullanıcılı ilk testte olduğu gibi.

Ayrıca pm stratejisini dinamik olarak ayarlarken php-fpm’nin nasıl çalıştığını da görebilirsiniz. htop’u çalıştırırsanız, başlangıçtaki işçi sayısını göreceksiniz.

ve eğer testi çalıştırırsanız, o zaman kademeli olarak çalışan sayısı önce mevcut maksimuma yükselecektir.

ve testin bitiminden sonra ilkine düşecektir.

Author avatar
omurakbs_5tka5sij
https://wegdi.com

Yorum gönder

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir