Nginx + FastCGI / FPM

Ich habs nun endlich gewagt und den Predb Server auf FPM statt FastCGI direkt umgestellt, und muss sagen: Ich bin begeistert.

Anders als Fastcgi crasht FPM nicht alle 20Minuten und erfordert einen Kill des Prozesses und Neustart (aka evil ‘504 Gateway Timeout’), anders als früher ist FPM jetzt im PHP Core und muss nicht mehr extern gepatcht werden (ab 5.3.3).

Einfache Installation (Debian):

apt-get update
echo “deb http://php53.dotdeb.org stable all” >> /etc/apt/sources.list
apt-get update
apt-get install php5-cli php5-common php5-suhosin
apt-get install php5-fpm php5-cgi
apt-get install php5-mysql php5-gd
/etc/init.d/php5-fpm restart

Fertig (nginx muss vorher natürlich für PHP/FastCGI auf Port 9000 konfiguriert gewesen sein) – nach ersten Messungen bringt FPM gegenüber FCGI mind. 30% mehr Geschwindigkeit und 60% mehr Stabilität.
Der Wechsel lohnt sich also.

Wenn jemand will Bau ich da mal ein Ubuntu/Debian Bash Script das den neuesten (stable) Nginx compiled und mit PHP + wahlweise MySQL installiert.

This entry was posted in Uncategorized. Bookmark the permalink.

5 thoughts on “Nginx + FastCGI / FPM

  1. (thumbsup) for using state-of-the-art (php-fpm) 😉

    ein Geschwindigkeitsvorteil konnte ich messbar nicht feststellen. Dafür einen unheimlichen Stabilitätsvorteil. Früher mussten wir sehr oft FastCGI killen (leider ging das killen auch nicht immer problemlos – vor alleim bei hohem Traffic) weil er sich aus dem Backlog nicht wieder erholen konnte (die berühmten 504 Errors).

    Seit der Umstellung läuft der Server nun mit einem Uptime von 44 Tagen ohne die PHP-Prozesse neu zu spawnen. Mittels Slow-Log / Dynamic Spawning lässt sich gut debuggen welche PHP-Skripte eine zu lange Laufzeit haben.

    Kleiner Tipp: PHP-FPM nicht vie TCP/IP ansprechen sondern socket, und socket entsprechend auf /dev/shm lagern – dürfte nochmal etwas schneller sein.

  2. Jein, völlig stabil ist es bei mir auch nicht, nach etwa 3-4 Tagen frisst FPM so viel ram das ich es mal neu starten muss (was problemlos via Cron geht), dauert 5-10s und reduziert die ram usage wieder enorm.

    Mal anschauen wie das mit Socket über nginx statt TCP läuft, bin ja für alles offen das mehr Geschwindigkeit bringt.

  3. folgendes musst du gegenchecken:

    -> wieviele requests/s
    -> wieviele php-fpm prozesse zu dieser Zeit

    requests/s (vor allem bei lighttpd/nginx) muss viel höher sein als die anzahl der php-fpm prozesse. sonst heisst es im umkehrschluss: deine php-skripte brauchen länger als eine Sekunde für die ausführung (meistens liegt es an suboptimale mysql-queries -> cachen?). via php-fpm-slowlog kriegste heraus welcher php-skript dafür verantwortlich ist. via mysql slow log welcher sql-query 🙂

    Dann naütrlich nur soviele Prozesse starten wie RAM / php-memory-limit, da man ja davon ausgehen muss dass jede PHP-Anfrage (vor allem bei einem Angriff) das volle memory_limit ausnutzen könnte.

    Also wir haben nach den optimierungen (mysql / php-fpm.conf) keine Probleme mehr – auch bei Peaks. RAM verbrauch ist sehr stabil

Comments are closed.