Warum du php-fpm statt mod_php für Shopware verwenden solltest…

Ich habe bereits in einem vorherigen Post verschiedene Webserver und PHP Handler miteinander verglichen – in diesem Beitrag möchte ich noch einmal auf ein Live Setup eingehen, in welchem mod_php sicher keine Wahl darstellt.

Wann lohnt sich Shopware mit mod_php?

Du hast ein kleines Projekt, zum Beispiel zum testen, oder einen kleinen Nischen-Shop mit weniger als 30rpm (Requests per Minute) und es läuft nur eine Shop (keine Subshops).

In diesem Fall reicht sicher ein Standard Apache2 Setup aus, welches von den meisten Hostern angeboten wird. Sobald man sich aber in den Bereich von mehreren Subshops (in diesem Fall 6), 300-400rpm und täglichen Deployments bewegt ist dies nicht mehr funktional. Warum?

Im erwähnten Live Setup werden nach einer Änderungen versch. Caches geleert – in manchen Fällen auch einfach alle Caches via ./var/cache/clear_cache.sh Was dann passiert zeige ich euch am besten Kurz in einer Grafik von meinem Testsetup:

Im Testcase werden 1080 Requests auf alle Subshops abgesendet (Detailseite, Kategorielisting, Startseite – 3 x 6 Shops x 60 Threads). Das ist eine übliche Belastung bei größeren Shops zu Hochzeiten. Natürlich sind durchschnittliche Antwortzeiten von 24 Sekunden absolut inakzeptabel.

Dazu noch ein Screenshot der CPU Auslastung und RAM Verbrauch:

Wie man sieht ist die CPU komplett überfordert und schmiert auch im „worst case“ einfach ab. Der Ram Verbrauch ist im Vergleich auch wesentlich höher.

Apache2 mit php-fpm

Wir haben mit unserem Hoster mehrfach über das Thema gesprochen. Dort hat man aber stets an Shopware verwiesen, die vom Entwickler Support sollten sich darum kümmern. Was meint Ihr, Hostersache oder Shopsoftware Sache? Schreibts mal in die Kommentare, würde mich interessieren.

Also dann schauen wir uns mal den exakt selben Test mit php-fpm an – dazu müsst Ihr nur eure Config anpassen, den mod_php deaktivieren und php-fpm aktivieren. Apache neustarten und los geht es:

Wie man sieht schafft es hier der Apache wesentlich schneller – im Schnitt ist der Abbau der Requests fünfmal so schnell. Beeindruckend! Schauen wir uns noch die CPU Auslastung an:

Der Ramverbrauch ist knapp 4GB geringer und die CPU arbeitet alle Requests wesentlich entspannter ab.

Ist damit schon das Ende der Fahnenstange erreicht? Nein! Ich möchte noch kurz meine Messwerte vom NGINX mit euch teilen:

Mit knapp einer Minute ist hier NGINX klar der führende Webserver, zu mindestens beim initialen Aufruf nach dem Cache leeren. Die CPU Auslastung und der Ram Verbrauch sehen ähnlich aus wie beim Apache2 mit php-fpm.

Solltest du also direkt NGINX nutzen? Falls du einen neuen Shop aufbauen solltest, oder gerade deinen Hoster wechselst, definitiv. Wenn du schon php-fpm nutzt muss man vorab den Mehrwert einschätzen und ausreichend testen – nicht alle Hoster bieten NGINX an und laut Shopware wird er auch nicht offiziell unterstützt, obwohl ich viele Setups bereits mit NGINX aufgesetzt habe – no Problemo.

Warum nun also ist der Titel „Warum du php-fpm statt mod_php für Shopware verwenden solltest…“? Der Satz wird fortgesetzt mit:

… wenn du die Wahl hast oder dein aktuelles Setup ähnliche Probleme hat. Dann solltest du definitiv wechseln – denn selbst wenn dein Shop noch kein php-fpm brauch, man möchte ja im besten Fall wachsen und eine kleine mod sollte da die 30 Minuten Mehraufwand wert sein.

 

5 Antworten auf „Warum du php-fpm statt mod_php für Shopware verwenden solltest…“

    1. Danke für den Hinweis, habe ich in dem Fall falsch beschrieben. In dem Beispiel habe ich php-fpm genutzt – den Unterschied zwischen beiden findest du HIER – habe den Beitrag angepasst (php7.0-fpm vs. mod_php)

  1. Ich bin heute zufällig über den Blogpost gestolpert. Der Hauptgrund warum mod_php langsamer ist, liegt an mpm-prefork. Wenn man mod_php aktiviert, kann der Apache die Threads nur im prefork Modus abarbeiten – d.h. pro Request ein eigener Apache-Prozess. Bei CGI/FPM kann man mpm-worker oder mpm-event nutzen, die deutlich besser skalieren und bspw. nur verschiedene PHP-Prozesse aufmachen.

    prefork: https://httpd.apache.org/docs/2.4/de/mod/prefork.html
    event: https://httpd.apache.org/docs/2.4/de/mod/event.html
    worker: https://httpd.apache.org/docs/2.4/de/mod/worker.html

    mod_php hat aber natürlich den Vorteil, dass man kaum etwas konfigurieren muss und auch die Zugriffsrechte „ootb“ keine Probleme machen. Das ist bei cgi/fpm sicherlich etwas umfangreicher.

    Danke schonmal für deinen Beitrag!

    1. Hi Moritz,
      danke für die weiteren Info’s. Das mit den Apache Prozessen war wirklich bei höherem Traffic ein Pain und hat unglaublich viel RAM gefressen.

      Genau, das aufsetzen von einem Apache mit mod_php ist wesentlich simpler und mache ich auch bei einigen privaten Projekten so (lokal nutze ich abwechselnd Apache FPM/NGINX)

      PS: Wir haben mittlerweile unseren Hoster gewechselt. Dieser hat uns sofort FPM angeboten, denn er hat das Problem bei 7 Subshops / Cache leeren und moderatem Traffic erkannt. Da sind uns nämlich des öfteren mal die Appserver einfach abgeschmiert :/

  2. Hi Moritz,
    wie sieht denn eine standardmäßge Konfiguration deiner php-fpm Umgebung aus? Wir haben immer mal wieder Probleme, dass der Server den php-fpm Prozess abschiesst wenn zuviel Traffic drauf geht. Beispielsweise bei cache warmup mit Stapelgröße von 1000 und mehr Requests.

Schreibe einen Kommentar zu micha Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert