Server-Optimierung

Veröffentlicht: von & gespeichert unter News.

max_input_vars und memory_limit: Bei den Meisten zu klein für Prestashop

PrestaShop ist eine Webanwendung, die in der weitverbreiteten Web-Programmiersprache PHP verfasst ist und deshalb alle Vor- und Nachteile dieser speziellen Umgebung mitbringt. PHP wurde zuerst 1995 veröffentlicht und wird demnach in 2015 schon 20 Jahre alt — so alt wie JavaScript, etwas jünger als Perl, etwas älter als Python. PHP ist damit ein wahrer Veteran unter den Sprachen, die das Web im Backend maßgeblich mitgeformt haben.

Anders als bei Python, Perl und serverseitigem JavaScript ist bei PHP die Erzeugung von HTML und die Einbindung in einen Webserver (in der klassischen Konfiguration ist dies Apache) von Anfang an in das Design der Sprache eingeflossen – unter anderem auch mit der Folge, dass von den ca. 650 Parametern die in einer php.ini (dem Haupt-Konfigurationsfile von PHP) stehen können sich nicht wenige direkt darauf auswirken, wie sicher und wie leistungsstark eine PHP-Anwendung sich auf dem Web verhält.

Ein Problem stellen diese Konfigurations-Parameter immer dann dar, wenn sie nicht im Einklang stehen mit den Anforderungen der jeweiligen Webanwendung. Es dürfte klar sein, dass die Grundeinstellungen oftmals nicht optimal sein werden, denn schließlich können die PHP-Autoren unmöglich jede Einzelanwendung vorhersehen – bestenfalls können die Default-Werte typisch Anwendungen und Gegebenheiten abbilden. Zu solchen typischen Allerwelts-Anwendungen gehört PrestaShop aber nicht mehr, dafür ist es zu leistungsstark, sind die Konfigurationsmöglichkeiten zu umfangreich geworden.

An dieser Stelle werden aufmerksame Leser zu Recht fragen: Was haben die Konfigurationsmöglichkeiten von PrestaShop mit den Grundeinstellungen von PHP zu tun? Die Antwort lautet: max_input_vars, kurz für ‘maximale Anzahl von Eingabewerten in Web-Formularen’. Dieser Wert wurde in PHP 5.3.9 (Anfang 2012) eingeführt und soll über die Beschränkung der Anzahl der in einem einzigen HTTP-Request verwendbaren Werte dazu beitragen, PHP-Anwendungen widerstandsfähiger gegenüber sogenannte Hash-Collision-Attacks zu machen. Als Default wurden 1000 Formularwerte je Anfrage festgesetzt – welches Web-Formular hat schon mehr als tausend Eingabefelder?

Leider führt der Standardwert von max_input_vars = 1000 bei PrestaShop dazu, dass ein zentraler Baustein für die Anpassung eines Shops an örtliche Gegebenheiten und Vorgaben des Betreibers nicht mehr funktioniert, nämlich das Web-Formular, in dem für jede Frontend-Sprache die Übersetzungen aufgeführt werden. Dieses eine Formular kann schnell über 5000 statt der zulässigen 1000 Werte aufweisen und führt dann regelmäßig zu einer Fehlermeldung.

Aber auch das Update eines komplexen Produkts mit vielen Variationen und Detailangaben kann das Limit durchbrechen, weil jede Variation mit allen Angaben zu speichern ist, sich also die Anzahl der Einzelangaben zur Anzahl der Variationsparamter quadratisch verhält (z.B. eine Jacke, zwei Schnitte, sechs Farben, vier Größen, jedes Produkt mit Preis, Text, Stichwort versehen führt schon zu 1 × 2 × 6 × 4 × 3 = 144 verschiedene Angaben). In der Logdatei stellt sich dieses Symptom dann ungefähr wie folgt dar:

2014/10/28 20:41:42 [error] 11812#0: *1721 FastCGI sent in stderr: "PHP message: PHP Warning:
Unknown: Input variables exceeded 1000. To increase the limit change max_input_vars in php.ini. in
Unknown on line 0" while reading response header from upstream, client: 123.123.123.123, server:
somesite.com, request: "POST /manager/?a=2&class=product&method=edit HTTP/1.1", upstream:
"fastcgi://unix:/tmp/somesite.com.sock:", host: "somesite.com", referrer:
"http://somesite.com/manager/?a=2&class=page&method=productedit&product_id=8"

Eine weitere Beschränkung mit der PrestaShop-Betreiber rechnen müssen wird durch die PHP-Variable memory_limit verursacht.

“128M” PHP_INI_ALL “8M” before PHP 5.2.0, “16M” in PHP 5.2.0

    All modules cannot be loaded due to memory limit restriction reason,
    please increase your memory_limit value on your server configuration

1024MB (also ein Gigabyte!)

 

Schnellere Infrastruktur: SPDY und HTTP/2

Wer viel mit der technischen Seite des Internets und des World Wide Webs zu tun hat lebt in einer Welt des beständigen Wandels; fortlaufend kommen neue Browserversionen mit neuen Features, neue Endgeräte, neue JavaScript-Versionen, neue Software usw. auf den Markt und wollen beachtet werden.

Gleichwohl ändern sich manche Dinge ehere langsam, und hierzu gehören – vielleicht verständlicherweise – manche Aspekte der Infrastruktur. IPv6, der Ersatz für das gegenwärtig immer noch dominante IPv4-Protokol zur Adressverwaltung und Verbindungsherstellung, wurde schon 1998 im Wesentlichen verabschiedet, hat sich aber noch längst nicht überall durchgesetzt: statt dessen wird nach wie vor weithin die Version 4 von 1980 verwendet, die demnach bereits seit 35 Jahren im Einsatz ist.

Das HTTP-Protokoll, dass die Abfrage-Antwort-Kommunikation zwischen Webbrowser und Webserver regelt, ist (im Kern) 9 Jahre jünger als IPv4, hat aber seitdem immerhin schon drei Updates durchgemacht, wobei die aktuelle Version HTTP/1.1 aber auch schon seit immerhin 16 Jahren gültig ist. Diese Liste gibt eine anschauliche Übersicht:

  • 1980 – IPv4
  • …
  • 1989 – HTTP pre-0.9
  • 1990 – …
  • 1991 – HTTP/0.9
  • 1992 – …
  • 1993 – …
  • 1994 – …
  • 1995 – …
  • 1996 – HTTP/1.0
  • 1997 – …
  • 1998 – IPv6
  • 1999 – HTTP/1.1
  • 2000 – …
  • 2001 – …
  • 2002 – …
  • 2003 – …
  • 2004 – …
  • 2005 – …
  • 2006 – …
  • 2007 – …
  • 2008 – …
  • 2009 – Google started das SPDY-Projekt
  • 2010 – …
  • 2011 – IANA vergibt die letzten IPv4-Adressblöcke
  • 2012 – …
  • 2013 – …
  • 2014 – …
  • 2015 – Google kündigt Aufgabe von SPDY zugunsten von HTTP/2 an
  • 2016 – ?

Seit HTTP/1.1 eingeführt wurde ist das Web nicht nur in der Zahl der aktiven Anbieter und der Zahl der passiven Teilnehmer stark gewachsen, es hat sich auch zum omnipräsenten Medium entwickelt. Wir leben in einer Zeit, in der die Benuzung eines Smartphones zum guten Ton gehört, fast alle fast immer online sind, und der einstmals eher passive Leser von einzelnen Webseiten sich immer mehr zum aktiven Teilnehmer in allerlei sozialen Netzwerken entwickelt hat.

Mit dem erhöhten Traffic (sowohl über das gesamte Web betrachtet als auch hinsichtlich einer einzelnen Webseite) wachsen auch die Chancen, dass Optimierungen im Übertragungsprotoll deutliche Auswirkungen auf die Responsitivität von Webinhalten haben. HTTP/1.1 ist ein relativ naives Protokoll, dessen Vorzug in seiner Einfachheit liegt: HTTP/1.1…

  • ist ein reines Request/Response-Protokoll, das
  • klar zwischen Server (Anbieter) und Client (Konsument) von Inhalten unterscheidet;
  • eine Verbindung kann immer nur von Client begonnen werden und wird mit einer einzelnen Antwort vom Server quittiert; dabei
  • kann der Client nur Abfragen machen und der Server nur Antworten geben.

Daraus folgt unter Anderem, dass z.B. zur Darstellung einer einfachen Webseite mit einem Text und einer dazugehörigen Abbildung folgender Ablauf einzuhalten ist:

  1. Der Benutzer ‘geht auf eine Webseite’ (zum Beispiel durch Eingabe der URL http://example.com/beispiel.html in der Adresszeile).
  2. Das veranlasst den Browser, an das Netzwerk eine Anfrage zu schicken; als Antwort erhält es eine mit HTML-Codes versehene Textdatei.
  3. Dieses HTML-File wird vom Browser analysiert (‘geparst’) um das Markup vom eigentlichen Text zu trennen und weitere Resource-Adressen zu finden; in unserem Beispiel finde es das Image-Tag <img src='http://example.com/image.png'>.
  4. Nun weiß der Browser, dass zur Darstellung der Seite auch die Datei http://example.com/image.png benötigt wird, also wird eine zweite Anfrage an das Netzwerk geschickt und wieder auf die Antwort gewartet.

Man beachte dass Schritt 4 für jedes Bild, jedes Stylesheet und jedes JavaScript-File zu wiederholen ist, bevor die Seite komplett widergegeben werden kann – und das bedeutet, dass ein Browser oft dutzende von HTTP-Requests formulieren und über die Leitung schicken muss. Jede Abfrage bringt dabei eine Grundbelastung für das Netz mit, egal ob die angefragte Resource wenige Bytes oder mehrere Megabytes groß ist. In der ursprünglichen Version von HTTP/1.0 hat darüberhinaus noch jede HTTP-Anfrage zwingend die Eröffnung einer Client-Server-Verbindung auf der unterliegenden TCP-Ebene bedeutet, was seither aber durch sogenannte Keep-Alive Connections Vergangenheit geworden ist.

Ambieter von Webseiten haben im Wesentlichen zwei Techniken entwickelt um den Beschränkungen von HTTP auszuweichen und schnellere Ladezeiten zu ermöglichen, nämlich einerseits die Aufteilung der Inhalte auf mehrere Server-Adressen, so dass mehr Abfragen parallel laufen können (domain sharding; hierher gehören im Prinzip auch CDNs, also Content Delivery Networks) und andererseits die Zusammenfassung von Inhalten in weniger Dateien (resource merging; hierher gehören neben dem Zusammenfassen von JavaScript und CSS-Dateien auch Sprites (viele kleine Bilder in einem großen), das Inlinen von JavaScript und CSS in die HTML-Datei und Data-URLs). Unnötig zu sagen, dass diese Techniken nicht nur Arbeit und Kosten verursachen, sondern auch dazu beitragen, Webinhalte unübersichtlicher zu machen.

HTTP is the fundamental networking protocol that powers the web. The majority of sites use version 1.1 of HTTP, which was defined in 1999 with RFC2616. A lot has changed on the web since then, and a new version of the protocol named HTTP/2 is well on the road to standardization. We plan to gradually roll out support for HTTP/2 in Chrome 40 in the upcoming weeks.

HTTP/2’s primary changes from HTTP/1.1 focus on improved performance. Some key features such as multiplexing, header compression, prioritization and protocol negotiation evolved from work done in an earlier open, but non-standard protocol named SPDY. Chrome has supported SPDY since Chrome 6, but since most of the benefits are present in HTTP/2, it’s time to say goodbye. We plan to remove support for SPDY in early 2016, and to also remove support for the TLS extension named NPN in favor of ALPN in Chrome at the same time. Server developers are strongly encouraged to move to HTTP/2 and ALPN.—Chromium Blog

http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol http://en.wikipedia.org/wiki/HTTP/2 SPDY: https://developer.chrome.com/multidevice/data-compression#spdy http://nginx.com/blog/how-nginx-plans-to-support-http2/

Chrome supports HTTP/2 by default (verified as of version 41 using Akamai's HTTP/2 browser support detector). Currently only HTTP/2 over TLS is implemented.[46] As of February 2015, Google plans to fully implement HTTP/2 in future versions of its Chrome browser and will remove support for SPDY.[47]
Google Chrome Canary supports HTTP/2 by default (verified as of version 43 using Akamai's HTTP/2 browser support detector). Canary version 43 supports identifying servers using the final version of the draft (h2-17) as indicated on this post by Ilya Grigorik
Chrome for iOS supports HTTP/2 by default (verified as of version 41 using Akamai's HTTP/2 browser support detector).
Firefox supports HTTP/2 which has been enabled by default since version 36.[48] Experimental support for HTTP/2 was originally added in version 34.[49][50] Currently only HTTP/2 over TLS is implemented.[21]
Internet Explorer supports HTTP/2 in version 11, but only for Windows 10 beta, and is enabled by default. Currently only HTTP/2 over TLS is implemented.[51]
Opera supports HTTP/2 by default (verified as of version 28 using Akamai's HTTP/2 browser support detector).
Our Score