Webserver Performance – Viel Lärm um nichts?

Für ein gutes Suchmaschinen-Ranking und einen kommerziellen Erfolg ist eine gute Website Performance Pflicht. Eine Website wird demnach gebaut, online gestellt und ein Test wie Google PageSpeed Insights oder WebpageTest wird initalisiert. Ist das Ergebnis zufriedenstellend, muss ab diesem Zeitpunkt nicht mehr weitergelesen werden.

Kommen die Tests jedoch zu dem Schluss, dass die Page verbesserungswürdig ist, frei nach dem Slogan eines bekannten Baumarktes: "Es gibt immer etwas zu tun", dann ist noch Arbeit notwendig. Bei der Suche nach Verbesserungen sind unzählige Tipps zu finden wie und in welcher Weise gewisse Aspekte geändert werden sollen, sodass die ganze Page schneller wird.

Tipps wie:

• Filesystem mit noatime mounten
• Bei apache .htaccess deaktivieren
• mpm_event statt mpm_prefork
• Ein CDN verwenden
• HTTP/2 verwenden
• Nginx statt Apache verwenden
• und anderes

Sehr oft kommen dann Tuningmaßnahmen zum Einsatz die vielleicht die Skalierbarkeit verbessern, aber nicht sehr hilfreich sind wenn die Seite schon beim ersten Besucher langsam ist. toscom hat unterschiedliche Stacks unter die Lupe genommen, Performancemessungen gemacht und hier zusammengefasst welche Tipps einen Versuch wert sind und welche eher nicht.

noatime

Ist eine Mountoption für Filesysteme. Das atime steht für "Access Time", und ist ein Timestamp für Dateien und Verzeichnisse (inodes) der bei jedem Access neu gesetzt wird. Dadurch kann ausgelesen werden, wann das letzte mal auf eine Datei zugegriffen wurde. Bei einem Webserver der viele Besucher hat ist das meist keine sehr wertvolle Information.

Da sich mittlerweile die Mountoption relatime – welches ein Kompromiss ist zwischen die atime bei jeden Zugriff oder gar nicht zu aktualisieren ist – als Standard durchgesetzt hat, bringt dieser Tipp nichts mehr.

.htaccess

Der Apache Webserver hat die Möglichkeit Konfiguration in Dateien auszulagern die im Webroot liegen. So kann ein Webentwickler ohne root-Zugang die Konfiguration des Webservers beeinflussen. Wenn diese Option aktiviert ist, was der Normalfall ist, muss der Webserver in jedem Verzeichnis auf das er zugreift zuerst mal kontrollieren ob es eine .htaccess Datei gibt die er auswerten muss. Diese zusätzlichen Fileoperation kosten Zeit. Im Apache lässt sich das deaktivieren, Nginx unterstützt so eine Funktion gar nicht.

In unseren Tests ist es uns nicht gelungen die Differenz von extern zu messen, etwaige Unterschiede gehen in der Netzwerklatenz unter. Viele Webapplikationen bringen von sich schon Konfigurationen in einer .htaccess mit, um Zugriff auf gewisse Pfade zu unterbinden oder auch Rewrites zu realisieren. Deaktiviert man die .htaccess muss man die Konfiguration aus allen .htaccess Dateien händisch in die Webserverkonfiguration einpflegen.

HTTPS

Mittlerweile gehört es nicht nur für Webshops zum guten Ton Seiten über verschlüsselte Verbindungen anzubieten. Durch den zusätzlichen SSL-Handshake und den Verschlüsselungsoverhead verzögert sich die Auslieferung der Seite.

In unseren Test hat sich die Auslieferung um ~ 200ms verzögert. Auch die neuere Version HTTP/2 die unter anderem Komprimierung der Header und Multiplexing unterstützt war nicht schneller sondern in einzelnen Testdurchläufen sogar langsamer.

CDN

Bei einem CDN (Content Delivery Network) handelt es sich um ein Netzwerk das statischen Dateien abhängig von der geografischen Lokation des Users ausliefert. Diese Netze versprechen geringe Latenzen und sind für das Ausliefern von statischen Dateien optimiert. Der eigentliche Webserver wird dadurch entlastet und die Ladezeit der Seite verkürzt sich für den Kunden. Aber dafür ist auch eine zusätzliche DNS-Abfrage erforderlich.

Der von uns gemessen Vorteil liegt bei 200-300ms.

Browser caching

Über Header lässt sich festlegen ob und für wie lange der Browser Dateien speichern darf. Bei statischen Dateien natürlich sehr sinnvoll.

Bringt, ab dem zweiten Laden der Seite, viel. Ist auch oft schon durch das Aktivieren des expires Moduls im Apache erledigt.

Nginx statt Apache

Nginx ist ein moderner Webserver der unter anderem von Haus aus auf Threads statt Forking setzt und auch keine Unterstützung für .htaccess Dateien hat. Dadurch ist er per Default schon mal nicht schlecht aufgestellt. Wenn bei Apache .htaccess deaktiviert wird und mpm_event (Threads) als Worker verwendet wird schmilzt der Vorsprung auch gleich wieder.

TTFB

Sehr oft merken Performancetests an, dass die "Time to first byte" (oder auch server response time) besser sein könnte, dabei wird gemessen wieviel Zeit zwischen der Anfrage an eine Seite und dem Erhalt des ersten Byte vergeht. Unter der Annahme dass kein altersschwacher Server an einer ganz langsamen Leitung verwendet wird und der Wert auch ohne Last schlecht ist, kann dieser Wert über Änderungen am Webserver oder dem zugehörigen Stack kaum beeinflussen werden. Die Zeit geht meistens in der Datenbank verloren und ist oft auch gar nicht so von der Hardware abhängig. Manche Seiten führen hunderte SQL-Queries alleine für das laden der Startseite aus und die lassen sich durch SSDs, CPUs und Memory nur bedingt beeindrucken.

Hier ist es ratsam einen Full Page Cache zu verwenden.

Weiterführende Links:

• https://developers.google.com/speed/pagespeed/insights/
• https://www.webpagetest.org/