Webserver und Engines #

Dieser Abschnitt ist für Systemadministratoren und Produktmanager bei Hosting-Unternehmen, die entscheiden müssen, was eine Exponential-Website auf ihren Maschinen ausliefert, und es einrichten. Er beantwortet: hinter welchen Webservern und Engines Exponential läuft, welche das Projekt empfiehlt, welche zu welchem Hosting-Modell passt und wo die genauen Einstellungen stehen.

Warnung .htaccess bremst jede Anfrage. Sind .htaccess-Dateien erlaubt (AllowOverride alles außer None), geschweige denn genutzt, sucht Apache sie bei jeder Anfrage in jedem Verzeichnis des Pfads und liest und wertet sie aus, und die Ladezeiten der Seiten steigen drastisch (gemessen). Die einzige wirkliche Abhilfe ist, die Funktion für den virtuellen Host abzuschalten: AllowOverride None im virtuellen HTTPS-Host, und die Regeln in der Konfiguration des virtuellen Hosts selbst als mod_rewrite-Regeln. Das ist in Geschwindigkeitstests im Produktivbetrieb weit schneller und die Zeit für die Optimierung einer Produktivkonfiguration unbedingt wert. Stellen Sie sofort um: Übernehmen Sie die Regeln des Beispiels für einen virtuellen HTTPS-Host in Ihren virtuellen Host (mit dem statischen Cache auch staticcache_offload.conf), setzen Sie AllowOverride None, führen Sie apachectl configtest aus, laden Sie Apache neu und testen Sie die Website. Dieselben Regeln für andere Server: nginx, LiteSpeed, Caddy, IIS, Velocity (eingebaut); wohin Regeln für virtuelle Hosts in einem Control Panel gehören: Plesk, cPanel, DirectAdmin, ISPConfig. Unter LiteSpeed oder OpenLiteSpeed kann zusätzlich der Seiten-Cache des Servers anonyme Besucher und Crawler ohne PHP bedienen: Seiten-Caching mit LiteSpeed und OpenLiteSpeed.

Zurück zu Hosting-Unternehmen: hier beginnen.

Inhalt #

1. Die kurze Antwort
2. Die Server auf einen Blick
3. Seiten in diesem Abschnitt
4. Was jede Einrichtung gemeinsam hat
5. Verwandte Seiten

Die kurze Antwort #

• Exponential Velocity (die Engine qbix) ist der vom Projekt empfohlene Weg, eine Website in jeder Phase auszuliefern, von der Entwicklung bis zur Produktion. Es ist ein in PHP geschriebener Webserver, der die Anwendung in persistenten Workern geladen hält, wiederholte Seiten aus seinem eigenen Antwort-Cache beantwortet und HTTPS selbst ausliefert (Kapitel 8).
• FrankenPHP, gesteuert über denselben Befehl exp:velocity, ist die produktionsreife Alternative.
• Apache mit PHP-FPM und nginx mit PHP-FPM sind die klassischen Einrichtungen. Sie bleiben vollständig unterstützt und sind das, was Shared Hosting meist anbietet, weil Velocity einen dauerhaft laufenden Prozess braucht, den Shared Hosting meist nicht erlaubt (README.md, Abschnitt darüber, wann ein klassischer Server noch die richtige Antwort ist).
• Jeder andere Webserver, der eine Anfrage an PHP weitergeben und eine URL auf index.php umschreiben kann, liefert Exponential ebenfalls aus (Unterstützung von Betriebssystemen, Webserver).

Die Server auf einen Blick #

Die Stufen stammen aus Unterstützung von Betriebssystemen.

Hinweis Stufe 3 heißt „sollte funktionieren“: eine begründete Erwartung, kein Testergebnis (Die vier Stufen). Testen Sie einen Server der Stufe 3 auf einer Staging-Maschine, bevor Sie einen Tarif verkaufen, der davon abhängt.

Seiten in diesem Abschnitt #

Was jede Einrichtung gemeinsam hat #

Was auch immer die Website ausliefert, es gelten dieselben Regeln (Kapitel 8, Wie eine Anfrage ausgeliefert wird):

• Der Document Root ist das Wurzelverzeichnis der Installation, das Verzeichnis, das index.php enthält.
• Das Routing ist einmal aufgeschrieben, in .htaccess_root. Die Engines von Velocity und die erzeugte Konfiguration von FrankenPHP setzen dieselbe Liste Regel für Regel um. Apache (mit AllowOverride All) und LiteSpeed Enterprise lesen sie als .htaccess, die ./console exp:setup:htaccess --apply an ihren Platz kopiert; OpenLiteSpeed liest nur ihre Rewrite-Regeln (mit autoLoadHtaccess, nach einem Neustart); nginx, Caddy und IIS lesen sie nie (.htaccess und config.php von der Konsole einrichten).
• Keine PHP-Datei läuft, weil ihr Pfad angefragt wurde, außer den Front-Controllern in der Wurzel (index.php, index_rest.php, index_treemenu.php und, wenn SOAP an ist, index_soap.php; vor 6.0.15 hieß es soap.php, siehe Das SOAP-Einstiegsskript heißt jetzt index_soap.php).
• WebDAV braucht, wenn Sie es einschalten, eine eigene Regel für index_webdav.php (sein Name seit 6.0.15; webdav.php leitet bis zu einer späteren Hauptversion nur dorthin weiter) auf Apache, nginx oder IIS, auch im HTTPS-Host. Velocity liefert es nicht aus. Siehe Das WebDAV-Einstiegsskript heißt jetzt index_webdav.php.
• Nur aufgeführte Asset-Pfade werden als Dateien gesendet; settings/site.ini, die SQLite-Datenbank oder eine Quelldatei des Kernels, die per Pfad angefragt werden, erreichen index.php, nie die Datei.
• Der Benutzer, der PHP ausführt, muss var/ und die Verzeichnisse unter settings/ schreiben können, und ein Benutzer (oder eine Gruppe) sollte sie schreiben, welcher Server auch läuft (Kapitel 8, Dateiberechtigungen und Eigentum).

Prüfen Sie das Routing auf jedem Server mit den vier Anfragen aus Kapitel 8 und ersetzen Sie die Adresse durch Ihre eigene:

curl -s -o /dev/null -w '%{http_code}\n' https://example.com/.git/config                      # 404 (403 from qbix)
curl -s -o /dev/null -w '%{http_code}\n' https://example.com/kernel/classes/ezcontentobject.php  # 404
curl -s -o /dev/null -w '%{http_code}\n' https://example.com/robots.txt                        # 200 when the file exists
curl -s https://example.com/settings/site.ini | grep -c '^\[DatabaseSettings\]'                # 0

Ein 200 für die Anfrage an .git oder den Kernel bedeutet, dass die Regeln nicht aktiv sind. Halten Sie an und beheben Sie das, bevor die Website von außen erreichbar ist.

Verwandte Seiten #

• Hosting-Unternehmen: hier beginnen
• Leistung
• Kapitel 8: Die Website ausliefern
• Unterstützung von Betriebssystemen
• Velocity-Engines
• .htaccess und config.php von der Konsole einrichten
• Freie Dokumentation: Diese Seite darf unter der GNU FDL 1.3 frei kopiert, übersetzt und verbessert werden.