Viele Blogs und Content-Management-Systeme sind ziemlich mit dem Apache-Webserver verheiratet, insbesondere machen sie reichlich Gebrauch von den verfügbaren Apache-Modulen (rewrite, setenvif, expires, auth_basic, deflate, unique_id uvm).
Eingebürgert hat sich, dass die Einstellungen in dezentrale Konfigurationsdateien geschrieben werden, bei Apache in der Voreinstellung als .htaccess definiert (veränderbar mit der AccessFileName-Direktive). Manche Plugins passen die .htaccess-Dateien sogar sehr häufig an, beispielsweise um IP-Adressen zu blockieren oder durchzulassen.
Der Aufbau der .htaccess-Datei ist dabei leicht verständlich, da von oben nach unten zu lesen. Eine kurze if-Abfrage ob das entsprechende Modul vorhanden ist, danach die spezifischen Anweisungen. Hin und wieder gibt es vielleicht Konfigurationsfehler mit unschönen HTTP-Statuscode-500 „Internal Server Error“ Meldungen, weil die AllowOverride-Direktive in der Hauptkonfigurationsdatei eine spezifische Einstellung nicht erlaubt – aber im großen und ganzen hat sich das Schema bewährt (wenn auch nicht unbedingt unter dem Gesichtspunkt der Performance).
Seit einiger Zeit wird nun der Webserver nginx immer beliebter und dieser kennt keine dezentralen zur Laufzeit gelesenen Konfigurationsdateien. Vor allem die CMS‘, die stark auf mod_rewrite setzen und eine Menge Umleitungsregeln definiert haben, können oft nicht so schnell migriert werden.
Für PHP-Anwendungen mit großer mod_rewrite-etc.-Abhängigkeit, die aber trotzdem gut performen sollen, habe ich ein Setup mit nginx + Microcaching + Request-Limits, Apache mit mod_event (statt prefork) + mod_proxy/fcgi + PHP-FPM ausprobiert. Da gibt es zahlreiche Stellschrauben für die Performance; Hauptvorteil ist, dass die Ressourcen explizit definiert sind und eigentlich kaum der Fall eintritt, dass die Maschine 100% Last erreicht. Allerdings bin ich zu Beginn gleich in eine Situation geraten, in der ein CMS nicht mit PHP 7 lauffähig war, die ältere (distributionseigene) PHP-Version aber noch nicht den fastcgi-Patch hatte, der die besondere Art der sprechenden Pfade des CMS erlaubt hätte. So ist das Leben.
Trotzdem: Der Mittelsmann, hier Apache mit mod_event, soll auch noch weg. Eher früher als später. Glücklicherweise beginnen mehr und mehr Projekte, Profile für nginx zu entwickeln. Manche Anweisungen in liebgewonnenen oder unbedingt notwendigen Plugins lassen sich mit geübtem Auge auch selbst umschreiben. Dass nicht mehr die Reihenfolge, sondern die Spezifität der Anweisung entscheidend für die Ausführung ist, kann durchaus in unüberschaubare Situationen führen. Gute Kommentare oder auch Tests können da Abhilfe schaffen.
Ich baue gerade ein kleines Ansible-Playbook, in dem Apache nicht mehr vorkommt und nginx via fastcgi direkt mit PHP-FPM kommuniziert. Neben der Performance auch ein Gewinn an Übersichtlichkeit und einem Prozess weniger, dessen Ressourcen man messen, schätzen und anpassen muss.