Plesk und Nginx in 2021

In diesem Beitrag gehe ich auf die Verbesserungen ein, die Plesk bei der Konfiguration von Nginx in den letzten Jahren nach und nach eingebracht hat, insbesondere die im Januar 2021 bereitgestellte Brotli-Komprimierung – die standardmäßig eingeschaltet ist. Zudem werden Custom Templates für Nginx erläutert, den Stand bei Plesk von ModSecurity für Nginx untersucht, Nginx Caching erklärt und WordPress-Plugins empfohlen, die Nginx berücksichtigen.

Achtung: Dieser Artikel geht auf die Details von Plesk-Neuerungen bei Nginx ein. Aber nicht alle unten aufgeführten Neuerungen gehören zur Konfiguration die ich in den letzten Monaten für meine eigene Benutzung erarbeitet habe. Am Ende dieses Beitrags steht ein Fazit, zudem empfehle ich die jüngeren Artikel Nginx Konfiguration optimieren und Geld sparen sowie Plesk: Fail2Ban Jails für Nginx.

Plesk bietet den Webserver Nginx seit über 6 Jahren als schnellere und resourcenschonende Alternative zu Apache an. Nach standardmäßiger Plesk-Konfiguration (soweit das Nginx-Modul installiert ist) liefert Nginx alle Dateien der Webseite selbst aus, verwendet aber Apache im Hintergrund um z.B. PHP-Dateien auszuführen oder endgültige Dateinamen- und Pfade zu ermitteln. In dieser Konfiguration funktioniert Nginx als ein Reverse-Proxy Server. Der Hauptvorteil des Doppelpacks ist die Geschwindigkeit von Nginx aber ohne Probleme, weil die herkömmlichen .htaccess Dateien, die das Verhalten von Apache modifizieren, weiterhin greifen.

Je mehr man jedoch auf Apache verzichtet, umso mehr muss man das Wirken der .htaccess Dateien in der (statischen) Konfiguration von Nginx berücksichtigen. Das ist bei jeder Web-Software eine neue Herausforderung – WordPress, Drupal, Nextcloud, bbPress, Zabbix, WHMCS… alle brauchen eigene Konfigurationen für Nginx. Der Lohn dafür ist die Geschwindigkeit und Resourcenschonung, gerade wenn eine Website stark besucht wird zahlt sich das aus. Das liegt zum einen an der Konzeption von Nginx, aber auch daran dass er, im Gegensatz zu Apache, nicht bei jedem Zugriff in jedem Verzeichnis im Pfad schauen muss, ob eine (geänderte) .htaccess Datei nun vorliegt.

Lohnt es sich auf eine reine Nginx-Lösung umzusteigen? Ich meine in vielen Fällen ja – und die WordPress-Macher stimmen mir indirekt zu, siehe diesen Nginx-Artikel bei wordpress.org. Wenn mindestens eine Website an einem Server gut besucht ist, dann soll man meiner Meinung nach den Nginx-Weg für diese Website gehen – und dann kann man ihn auch für etwaige andere Websites auf dem Server einrichten, damit alle konform gehen.

Ich habe bereits mitte 2014 einen Artikel über Nginx und PHP-FPM bzw. einen 33-seitigen PDF geschrieben, der in seinen Grundsätzen noch erstaunlich aktuell ist. Zumal einige Schwächen in der Art wie Plesk Nginx PHP-FPM konfiguriert immer noch vorhanden sind, und von mir kürzlich als Bug-Report wieder angesprochen wurden – möge es bald Abhilfe geben.

Andererseits hat sich in den vergangen Jahren, und auch erst wieder kürzlich, einiges an Fortschritte gegeben wie Plesk Nginx konfiguriert und neue Features in Nginx anbietet. Grund genug, sie zu prüfen und die eigenen Gewohnheiten, Plesk – Nginx zu konfigurieren, zu überprüfen:

  1. Kann man inzwischen auf das eigene „Custom Template“ nginxDomainVirtualHost.php verzichten?
  2. Plesk bietet nun „ModSecurity“ für Nginx an – was ist das und soll man es einschalten?
  3. Welche WordPress-Plugins bieten Nginx-Konfigurationsergänzungen direkt an?
  4. Soll ich Nginx caching in Plesk einschalten (Antwort: eher Nein)
  5. Seit Version 18.0.33 (Anfang Februar 2021) schaltet Plesk das Brotli-Komprimierungsverfahren in Nginx standardmäßig ein – was ist das, was muss man tun?

Braucht man noch Custom Templates für Nginx?

Im oben verlinkten PDF steht auf Seite 13 eine veraltete Beschreibung „Alternative: Die Kontrolle an sich reißen“. Veraltet weil man mit Plesk heutzutage PHP-FPM per Nginx direkt in der Plesk-GUI einstellen kann. Dafür ist der Abschnitt „Die letzte Rettung: Custom Configuration Template“ auf Seite 15 noch voll aktuell; hier die aktuelle Beschreibung bei Plesk. Es ist und bleibt aber unschmackhaft, eigene Custom Templates zu benutzen – denn bei jedem Plesk-Update muss man sie kontrollieren und ggf. ergänzen.

Im oben erwähnten Bug-Report habe ich die immer noch vorhandenen Schwächen in den von Plesk erzeugten Nginx-Config für PHP-FPM detailliert dargestellt und um Behebung gebeten. Zum Zeitpunkt des Schreibens steht der Report auf dem Zustand „Forwarded to devs“ – somit wissen wir nicht, ob sie (bald) darauf eingehen werden. Wenn sie es tun, so weit dass ich damit zufrieden sein kann, dann werde ich künftig definitiv auf ein eigenes Nginx-Template verzichten. Wenn nicht, bin ich unentschieden – es gibt (dort notiert) ein „workaround“ für das Problem dass WordPress Blogartikel nicht gefunden werden (per nginx rewrite). Aber dann ist die eigene, reguläre Zusatzconfig für Nginx mehr „verkünstelt“ und mögliche Auswirkungen davon schwer einzuschätzen.

Doch es gibt weitere Faktoren für eine Entscheidung, was man nun insgesamt bzgl. Nginx-Config machen soll…

Plesk’s Angebot: ModSecurity für Nginx

Zunächst der Wikipedia-Eintrag zu ModSecurity. Leider nur auf Englisch verfügbar, daher der erste Absatz davon per DeepL übersetzt:

ModSecurity, manchmal auch Modsec genannt, ist eine Open-Source-Web Application Firewall (WAF). Ursprünglich als Modul für den Apache HTTP Server entwickelt, hat es sich weiterentwickelt, um eine Reihe von Hypertext-Transfer-Protokoll-Anfrage- und Antwort-Filter-Funktionen zusammen mit anderen Sicherheitsfunktionen über eine Reihe von verschiedenen Plattformen einschließlich Apache HTTP Server, Microsoft IIS und Nginx zu bieten. Es ist eine freie Software, die unter der Apache-Lizenz 2.0 veröffentlicht wird.

Es gibt eine Implementierung von ModSecurity für Nginx seit 2017, so dass es inzwischen ausgereift für den produktiven Einsatz sein dürfte. Erst in der zweiten Hälfte von 2020 kam dann das Angebot von Plesk – zunächst von Plesk selbst als „mit Vorsicht zu genießen“ ausgezeichnet, inzwischen nicht mehr.

Achtung: Am Ende der (recht brauchbaren) Plesk-Beschreibung zu ModSecurity steht (zum Zeitpunkt des Schreibens), dass es ModSecurity nur für Apache gibt. Das ist aber veraltet, im Changelog zu Plesk Obsidian 18.0.32 (freigegeben am 8.12.2020) steht dass ModSecurity für Nginx hinzugefügt wurde.

Achtung: Die o.g. Plesk-Beschreibung weist darauf hin, dass am eigenen Server ein lokaler DNS-Server eingerichtet sein soll, um aus ModSecurity stammenden DNS-Anfragen lokal zu cachen. Sonst könnte die Abarbeitung von HTTP-Anfragen spürbar verlangsamt werden. Wer ausschließlich seine Domains bei externen Providern verwaltet, hat womöglich aber das Bind-Modul im Plesk-Installer längst abgewählt (wie ich). Dann muss sie eben wieder installiert werden. Test ob Bind funktioniert (auf Shell-Ebene):
dig yourdomain.tld @127.0.0.1

Zunächst muss man per Plesk Installer „Web hosting | ModSecurity“ installieren. Und dann im Plesk GUI unter „Tools & Einstellungen | Sicherheit | Web Application Firewall“ aktivieren. Hierbei gibt es die Wahl zwischen „Nur Erkennung“ und „Ein“; die theoretischen Unterschiede sind im oben verlinkten Plesk-Artikel gut beschrieben. Wer vorsichtig vorgeht – zu empfehlen – kann erst „Nur Erkennung“ wählen, und im Laufe der nächsten Tage die ModSecurity Protokolle prüfen (bequem in der Plesk-GUI), was es alles blockiert hätte.

Sobald man ein Radio-Button „Nur Erkennung“ oder „Ein“ auswählt, erscheint im gleichen Plesk-Dialog darunter ein weiterer Bereich, wo man einen „Regelsatz“ auswählen muss. Das sind die Regeln, die steuern, wie die HTTP-Anfragen untersucht werden sollen – denn ModSecurity selbst ist nur ein Framework, leben tut es erst mit einem Regelsatz. Dabei bietet Plesk die gängigsten Regelsätze direkt zur Auswahl an – mit den Haken dass (a) manche davon kostenpflichtig sind und eine davon (Comodo) gratis aber registrierungspflichtig, und (b) man sowieso vor der Qual der Wahl steht. Ich habe mich im Internet informiert und lese, dass i.A. der Comodo-Regelsatz „benutzerfreundlich“ sei und nach Konsensmeinung die wenigsten „false positives“ erzeugt.

Zunächst aber muss man in der Dropdown „Regeln ausführen auf“ eben „Nginx (ModSecurity 3.0)“ wählen. Danach will man unter 5 angebotenen Regelsätzen seine Wahl treffen – aber jetzt, für Nginx, sind nur OWASP (zu streng) und Benutzerdefinierter Regelsatz auswählbar – Upps. Beide indiskutabel, hier müsste man Comodo wählen und seine gratis-erworbene Comodo-Kennung angeben können.

Im Changelog für Plesk 18.0.32 steht: At the moment you can only choose the OWASP ruleset in the Plesk UI for ModSecurity 3. You can download the Comodo ruleset and upload it to Plesk as a custom ruleset. We plan to make it possible to enable the Comodo ruleset for ModSecurity 3 directly from the Plesk UI in Plesk Obsidian 18.0.33.

Das ist aber in 18.0.33 leider noch nicht passiert. Wir sind zu früh daran – abwarten.

Update Anfang Mai 2021
Schlussendlich habe ich mich gegen den Einsatz von Modsec entschieden, warum steht unten im Fazit.

WordPress-Plugins die Nginx-Konfigurationsergänzungen direkt anbieten

Das soll hier keine ausführliche Liste sein. Ich erwähne nur die Plugins, die mir für Nginx-Unterstützung bekannt und im Einsatz sind. Von den Anforderungen her sind es am ehesten Sicherheits- und Cache-Plugins, die Veränderungen an der Webserver-Konfiguration vornehmen müssen.

  1. iThemes Security unterstützt bereits seit Jahren Nginx: Es schreibt einen Abschnitt mit Nginx-Regeln in eine Datei {docroot}/nginx.conf. Diese Datei wird nicht automatisch von Nginx gefunden, vielmehr muss man es in der eigenen Nginx-Config includieren. Die Regeln schützen z.B. Dateien und Verzeichnisse vor direkten Zugriffen, oder sperren bekannte Spambots aus.
  2. W3 Total Cache („W3TC“) benutzt ebenfalls diese Konvention und screibt seine Regeln zur Steuerung von Server- und Browser-Cachingverhalten in einen Abschnitt in dieselbe Datei. Die beiden vertragen sich also bestens und man selbst muss nur die eine Datei includieren.
  3. In letzter Zeit habe ich WP Cerber ausgewählt als Plugin das sowohl Hacking- und Malware als auch Spam-Angriffe entgegenwirkt. Noch berücksichtigt es Nginx nicht – aber ich konnte dem Autor per Support-Anfrage dazu bewegen, dass er versprochen hat, sich das Thema in Bälde anzunehmen.
  4. SEOPress

Soll ich Nginx caching in Plesk einschalten?

Schon länger bietet Plesk die Möglichkeit an, Caching in Nginx einzuschalten – {Website} | Einstellungen für Apache & nginx | nginx-Einstellungen | nginx-Caching aktivieren. Aber was bewirkt das, und ist es zu riskant? Zumal Plesk selbst dort schreibt: Caching kann die Reaktionszeit Ihrer Website, sowie die Serverauslastung verringern, sollte jedoch mit Vorsicht ausgeführt werden.

Ein kurzes Studium der Nginx-Literatur dazu – hier und hier – reicht um festzustellen, dass Nginx dann Kopien der auszuliefernden Dateien in einem eigenen Disk-Cache bereithält. Das mag einiges bringen, wenn Nginx als „Reverse Proxy“, also im Doppelpack mit Apache, benutzt wird, denn dann kann auf die Anfragen an Apache i.W. verzichtet werden und die Ergebnisdateien, die Apache einmal bereitstellt, immer wieder ausgeliefert werden. Damit handelt man sich allerdings ein großes Problem ein – wie soll Nginx feststellen ob die Ergebnisdateien noch aktuell sind, bzw. wovon ihre Aktualität abhängt? Unabhängig davon könnte ein Vorteil sein, dass Nginx dann fertig komprimierte Dateien (gzip oder brotli) vorhält, und sie nicht jedes Mal aufs Neue komprimieren muss.

Auch in der reinen Nginx-Lösung gibt es (abgesehen von vorkomprimierten Dateien) ein Szenario wo Nginx-Caching sinnvoll wäre – nämlich dann, wenn z.B. PHP-Dateien (mühsam) ausgeführt werden um den Inhalt einer Webseite zusammenzustellen. Ist das Ergebnis jedesmal gleich (z.B. Website ist „statisch“, d.h. erlaubt kein Login, kein Blogging etc.) dann wäre Nginx-Caching durchaus sinnvoll – wenn keine andere Instanz das nicht schon (besser) macht.

  • WordPress und andere CMSen
    Solche Programme haben alle eigene Caching-Plugins, die viel besser situiert sind zu beurteilen, wann eine Cache-Kopie veraltet ist. So fällt hier die Antwort eindeutig aus: Nein, kein Caching per Nginx.
  • Selbstgeschriebene Websites ohne eigenes Caching
    Ein gutes Beispiel aus meiner eigenen Arbeit ist hier Biblische Reisen. Ich habe die Website in PHP und jQuery Mobile realisiert, und auch den Import der aktuellen Reisedaten aus einem betriebsinternen System. Jeder Seitenabruf läuft momentan den ganzen Weg durch PHP, um die Seite zurückzuliefern. Dank OPCache und einen flotten Server mit großzügigen PHP-FPM Einstellungen, reicht diese Konfiguration für die aufkommenden Besucherzahlen vollkommen. Google PageSpeed Insights vergibt hier für Desktop 92 Punkte, die Auslieferung der PHP-Seite selbst dauert ca. 120 bis 180 Millisekunden. Ein Gewinn wäre mit Caching daher eher gering, und würde den Aufwand, eine Strategie zur Löschung des Cacheinhalts bei neuen Reisedaten zu entwickeln, nicht rechtfertigen.

Fazit: Caching in Nginx könnte (mit viel Vorsicht) sinnvoll sein, wenn Nginx als Reverse Proxy betrieben wird, oder bei extrem hoher Last (vorkomprimierte Dateien). Wird nur Nginx als Webserver benutzt, dürfte es nur wenige Szenarien geben, für die ein Caching so vorteilhaft wäre dass es den vermutlich bedeutenden Zusatzaufwand rechtfertigt.

Plesk und das Brotli-Komprimierungsverfahren in Nginx

Seit Version 18.0.33 (Anfang Februar 2021) schaltet Plesk das Brotli-Komprimierungsverfahren in Nginx standardmäßig ein. Wird Brotli nicht weiter konfiguriert (defacto zunächst der Fall) und es bleibt sonst die bisherige individuelle Konfiguration in Kraft, dann kann es in wenigen Fällen zu widerspruchlichen Antwort-Headers kommen. Plesk Doku beschreibt, wie man pro Domain oder insgesamt Brotli abschalten kann.

Aber erstmal: Brotli ist ein Kompressionsverfahren, das ähnlich wie beim eher bekannten Zip (bzw. gzip) Dateien packt bzw. komprimiert. Der Webserver packt die auszuliefernden Dateien und sendet die kürzeren Fassungen über das Internet zum Webbrowser, wo sie wieder entpackt werden vor ihrer Nutzung. Wenn die Zeit für das (Ent-)packen weniger beträgt als die Zeitdifferenz, die Originalfassungen über das Internet zu schicken, hat man einen Geschwindigkeitsgewinn (und belastet das Internet auch etwas weniger). Leider gibt es auf Deutsch nur wenig Information zu Brotli; hier auf Wikipedia, und hier auf englisch einen Vergleich von Brotli und Gzip. Unter dem Strich macht Brotli Dateien im Schnitt ca. 17% kleiner als Gzip.

Ab Plesk 18.0.33 sieht die Plesk-Config bzgl. komprimierte Auslieferung so aus:

  • Verfügbare Zusatzmodule sind: brotli.load, modsecurity.load, pagespeed.load
  • Ohne unser Dazutun werden per /etc/nginx/modules.conf.d/brotli.conf zwei Brotli-Module geladen (für „on the fly“ und Vorkomprimierung).
  • Und ebenfalls ohne Dazutun steht in /etc/nginx/conf.d/brotli.conf – der in http Kontext geladen wird:
    brotli on;
    brotli_types text/plain text/css application/json application/javascript application/x-javascript text/xml application/xml application/xml+rss text/javascript;
  • Hier eine Liste der verfügbaren Brotli-Direktive für Nginx. Dort fällt auf, dass Plesk auf die Direktive „brotli_comp_level“ verzichtet hat – der Default ‚6‘ (von 0 – 11) liegt in der Mitte und ist verm. ein guter Kompromiss zwischen gepackter Größe und die Zeit für das Packen.
  • In der Annahme, der Browser sagt im Request-Headers „accept-encoding: gzip, deflate, br“, und man hat in der eigenen Nginx-Config „gzip on“ (usw.) – was in Nginx’s server Kontext inkludiert wird: Dann anscheinend „trümpft“ die Brotli-Anweisung im http Kontext die Gzip-Anweisung im server Kontext, es wird tatsächlich ein Antwort-Header „content-encoding: br“ erzeugt und die Komprimierung dürfte dann wohl Brotli sein.
  • Das kann man sogar als elegant ansehen: Akzeptiert der Browser Brotli, dann wird Brotli benutzt, ansonsten die Gzip-Encoding wie bisher. Also, hier besteht kein Grund die eigenen Gzip-Anweisungen zu entfernen.
  • Handlungsbedarf gibt es jedoch bei WordPress mit W3 Total Cache: Das Plugin ist echt super – es macht sich die Mühe (wenn so konfiguriert) minimierte Dateien schon vorab per Gzip zu encodieren, und damit die Last der wiederholten Komprimierung durch den Webserver zu vermeiden. Dafür muss es selbst die Antwort-Header „content-encoding: gzip“ hinzufügen. Endergebnis: In der Antwort stehen beide Headers )-: So muss man entweder in W3TC die Vorkomprimierung per Gzip ausschalten, oder Brotli in der eigenen Domain-Config ausschalten („brotli off;“). Allerdings: W3TC bietet auch Brotli-Vorkomprimierung – wenn das entsprechende Zusatzmodul in PHP geladen ist (mehr hier) – was eher unwahrscheinlich ist, weil man (noch) das Modul hier abholen und selber kompilieren muss. Womöglich lohnt sich die Mühe: Die Direktive „brotli_comp_level“ gilt nur für „on the fly“ Komprimierung – was ahnen lässt, dass wenn Dateien vorkomprimiert vorgehalten werden, die maximale Komprimierung genutzt wird – ein gutes Argument, das Brotli-Modul in PHP zu integrieren so dass W3TC es nutzen kann.

Fazit mitte Februar 2021: Noch nicht handeln

abgesehen von der oben erwähnten Problematik mit W3 Total Cache. Sonst:

  1. Auf ein „Custom Template“ nginxDomainVirtualHost.php zu verzichten soll erst entschieden werden, wenn wir von den Plesk-Entwicklern hören zu meinen Verbesserungsvorschlägen.
  2. Bei ModSecurity warten wir auf eine Plesk-Version, die den Comodo-Regelsatz unterstützt.
  3. Derweil hoffe ich persönlich auf baldige Nginx-Unterstützung in WP Cerber.
  4. Nginx-Caching soll nur in besonderen Fällen verwendet werden.
  5. Die Brotli-Komprimierung läuft „out of the box“, und verträgt sich mit eigenen Gzip-Anweisungen.

Update Anfang März 2021: Es gibt Hoffnung

Plesk Dev-Team hat die wichtigsten Probleme in der Nginx-Config eingeräumt und „product issues“ dafür eingestellt.

Fazit Anfang Mai 2021

Mit Plesk 18.0.35 wurde deren Konfig für PHP-Dateien minimal angepasst:

Alt:
location ~ /$ {
  index <?=$VAR->quote($VAR->domain->physicalHosting->directoryIndex)?>;
}

Neu:
  index <?=$VAR->quote($VAR->domain->physicalHosting->directoryIndex)?>;

Die index-Anweisung steht jetzt ohne location-Einschränkung da, und tatsächlich klappt es nun mit WordPress-Permalinks. Ferner sind eigene Error-Dokumente für PHP-Scripts jetzt möglich.

Ich werde aber aus mehreren anderen Gründen weiterhin ein Custom-Template nginxDomainVirtualHost.php benutzen:

  • Manchmal (aber nicht immer) brauche ich unbedingt zusätzliche fastcgi-Anweisungen im PHP-Block, z.B. für Nextcloud oder für Websites mit anderen besonderen Anforderungen.
  • Mein Vorschlag mit „try_files“ wurde nicht umgesetzt (FPM wird auch dann aufgerufen wenn es die angeforderte PHP-Datei nicht gibt).
  • Es ist zwar möglich, die Plesk-location zuvorzukommen, so dass zwei PHP-Blöcke in der Konfiguration aktiv sind. Dann aber passieren seltsame Dinge, wie z.B. eine Aufdoppelung von Headers durch „add_headers“ (eine Anweisung, zwei gleiche Headers).
  • Plesk erzeugt grundsätzlich einen PHP-Block mit einem Regex für Webusers, die ich nicht haben will – ich erlaube keine und betrachte die Anweisung als mögliche Sicherheitslücke.

Eigene Nginx-Konfig und Fail2Ban anstatt Modsec

Bei meiner neuerlichen Arbeit an Sicherheit, am Server generell sowie bei WordPress, habe ich mich für WP Cerber als Sicherheits- und Anti-Spam-Plugin für WordPress entschieden – und bin bis jetzt sehr zufrieden damit. WP Cerber berücksichtigt Nginx nicht, daher habe ich die Nginx-Anweisungen, die von iThemes Security bislang erzeugt wurden, in eigener Konfiguration übernommen. Und manche 404-Fehler, z.B. der versuchte Abruf fehlender ausführbarer Dateien, mit Code 403 anstatt 404 quittiert. Somit kann ich die Access Logs mit einem Fail2Ban Jail für 403- und ähnliche Fehler belegen, so dass Angreifer alsbald direkt in der Server-Firewall ausgesperrt werden. Das klappt alles sehr gut. Nachdem ich mir so viel Mühe gegeben habe, die Logs und deren Überwachung schlank und trotzdem sehr effektiv zu machen, sehe ich keinen Grund mehr den Server mit Modsec und Bind9 zu belasten, die meine Optimierungen womöglich zunichte machen könnten.

2 Kommentare

zu Plesk und Nginx in 2021

  • Avatar schrieb am

    Hallo sehr geehrter Herr Reeves;

    sehr schöner Artikel und vielen Dank für Ihren Hinweis darauf bei Plesk.

    In heutigen Zeiten von SSD Platten, üppigen und günstigem Arbeitsspeicher in Verbindung mit schnellen *.core Prozessoren ist Caching jedoch immer unbedeutender.
    Wichtiger ist es, so viel der *.SQL Datenbanken im RAM zu halten, wie möglich.
    Einen Server nur mit NGinx zu betreiben ist mir zu heikel da das Zusammenspiel mit weiteren Komponenten sehr kniffelig sein kann und zusätzlichen Aufwand bedeutet. Im Gegensatz dazu ist ein Apache mit der richtigen Hardwareausstattung ein Kinderspiel, weithin kompatibel und keineswegs langsamer.

    Im Bezug auf Plesk sei gesagt dass wir da seit Plesk 7.x dabei sind und Plesk seit Version 9.x immer mehr dazu übergeht sein Pulver an zu vielen Schauplätzen zu verschießen. Alles machen, aber nichts mehr wirklich richtig.

    Das war auch die Intention meiner Antwort im dortigen Forum. Bevor sie eine neue Baustelle mit NGinx eröffnen sollten sie doch zuerst einmal den Apachen für moderne Bedürfnisse anpassen. Dahingehend ist heute nichts passier. http/2 sowie muss Brotli man selbst nachrüsten. Kein vernünftiger Admin betreibt seinen Server heute noch mit mod_php, was der einzige Grund wäre auch heute noch mit mod „Prefork“ anstelle von mod „EvenT“ zu konfigurieren.

    Würde (hier) Plesk seine Hausaufgaben machen und bestehende stabile Software modern konfigurieren bräuchte es das ganze GeCache nicht mehr und damit würden auch viele Fehlerquellen wegfallen und Ressourcen gespart.

    Mit freundlichem Gruß
    F.Häussler

    • Tim Reeves schrieb am

      Hallo Herr Häussler,

      vielen Dank für Ihr ausführliches Kommentar.

      Was Sie schreiben über mögliche Hardware-Aufrüstung ist sicherlich soweit richtig, doch eine monetäre Bewertung. Für mich, als leidenschaftlicher Resourcenschoner mit drei Töchtern, ist immer die erste Frage: Mit wie wenig ich das gewünschte Ziel erreichen kann.

      Auch dass die Arbeit mit Nginx kniffelig ist, habe ich schon selbst angedeutet, und gebe Ihnen dazu lauthals recht. Es war mir aber wichtig, die effizienteste Lösung zu finden, und dafür gehe ich die zusätzliche Meile – und schreibe solche Beiträge, damit andere Kollegen dies leichter selber machen können.

      Dass an Apache unglaublich viel optimiert wurde über die Jahre, ist bekannt. Dennoch scheint laut diesem Artikel von Kinsta der Siegeszug von Nginx ungebrochen – vermutlich weil er mit einer Architektur entworfen wurde, die die Schwächen von Apache überwinden sollte.

      Dass Plesk überraschend viele Schauplätze aufgemacht hat und einige davon suboptimal bedient, das sehe ich auch so. Ich habe eben viele Forumsbeiträge geschrieben und ein paar Vorschläge gemacht um Plesk besser zu machen – in den Punkten wo mir der Schuh gedrückt hat. Manches davon ist schleppend in Erfüllung gegangen 🙂

      Tim Reeves

Schreibe einen Kommentar

Bitte alle Felder ausfüllen. Deine IP-Adresse wird anonymisiert gespeichert. Fantasienamen und E-Mail Adressen (wie "donald@duck.org") werden akzeptiert.