Rasmus Lerdorf und die Geschichte von PHP

Rasmus Lerdorf lockte viele Zuhörer in seinen Vortrag: seine lustige und pragmatische Art ist einfach erfrischend und regt dazu an, mal etwas lockerer über bestimmte Themen nachzudenken.

PHP Entwickler müssten Rasmus Lerdorf kennen: er hat PHP erfunden.

1995 hat Rasmus seine ersten Schritte in Richtung PHP unternommen: Die erste Version von PHP bestand aus in HTML eingebetteten Kommentaren. In den Kommentaren standen einfache Befehl und direkte SQL Anweisungen.

Diese Version kannte noch keine geschweiften Klammern. Da Rasmus einige Spezifikationen zum Thema HTML (z.B. SGML) nur zur Hälfte jeweils gelesen hat, sind viele Dinge nicht so richtig Standard konform ( Zur Erinnerung: 1995 kannten nur wenige Menschen das Internet, in Deutschland tummelten sich mehrere Millionen Nutzer im Bildschirmtext-Netz. Internet Anwendungen basierten oftmals auf PERL und cgi.)

Warum ist PHP so erfolgreich? Dies hat mehrere Gründe:

  • es ist einfach zu lernen,
  • es ist skalierbar  (Facebook setzt PHP ein)
  • es ist einfach zu nutzen (auch für den Administrator). Andere Sprachen haben dem Entwickler zu viele Freiheiten gegeben (z.B. kann man mit Perl leicht einen shared Server lahm legen).

Einige Beispiele

  • Mit zwei Zeilen kann man einen Flickr Stream lesen und anzeigen.
  • Yahoo YQL – Zugriff auf Daten aus Facebook über eine Query-Language
  • Twitter  Beiträge, die in der Nähe getwittert wurde, auslesen

Fazit: „Die PHP Nutzer interessiert das Ergebnis und nicht wie elegant und schön der Weg dahin ist“. Das möchte ich nicht ganz bestätigen, nutzen doch inzwischen viele Entwickler Design-Pattern.

Zurück zur Zukunft von PHP: Was bringt PHP an interessanten Erweiterungen?

  • node.js and  PHP libevent
  • zeroMQ
  • gearman Integration (PHP-FPM). Für gearman werden wir bald in einem eigenen Blog-Beitrag vorstellen, es bietet insbesondere für komplexere eZ Publish Anwendungen sehr interessante Optionen.

Ein spannendes Thema ist und bleibt die Optimierung von Anwendungen. Höhere Bandbreiten der Nutzer belasten auch die Server mehr.

Laut Rasmus spielt die Wahl des Webservers keine große Rolle in Bezug auf Performance. Man sollte sich hier nicht auf Grundsatzdiskussionen einlassen, ob nun Apache, nginx usw. schneller sind oder nicht.
Wesentlich mehr Performance erreicht man mit anderen Mitteln:

  • Warnings kosten ca. 0.15 ms Zeit! Egal ob error_reporting an oder ausgestellt ist, es kostet Zeit. Der Grund ist, dass PHP die Fehlermeldung oder Warnung immer zunächst über ein sprintf erzeugt und erst dann prüft, ob die Meldung ausgegeben werden muss. Das könnte man optimieren, aber Rasmus hat zu Recht kein Interesse, dies zu tun. Die Optimierung der Anwendung sollte hier im Vordergrund stehen.
  • strace ist eine spannende Funktion. Sie zeigt nicht nur alle Funktionen, die aufgerufen wurden, sondern auch, ob z.B. Dateien nicht gefunden wurden. Fehlende Dateien kosten Performance. Wie funktionierts? In der Ausgabe von strace nach ENOENT ( Datei nicht gefunden) suchen und den Fehler beheben. Eine weitere Optimierung stellt der realpath_cache_size dar. Wenn strace aufzeigt, dass PHP trotz des caches das Dateisystem immer wieder durchsucht, dann kann dies an einer zu kleinen realpath_cache_size liegen. Die Grösse kann in der php.ini definiert werden.
  • Ein weiterer Tipp ist, hiphop zu nutzen, um nicht initialisierte Variablen etc. zu finden. hiphop ist ein Compiler, den Facebook entwickelt hat. Er übersetzt eine komplette PHP Anwendung in C++ Code und bindet einen Webserver hinzu. Die Anwendung inkl. einem Webserver kann so per cli (command line interface) gestartet werden.
  • Ein Tipp, der nicht  oft genug genannt werden kann ist, statische Dateien auf andere Domains auszulagern. Dies entlastet den Webserver und ausserdem laden die Browser auf mehrere Domains verteilte Dateien schneller.
  • Es sollte bei der Ausgabe von Daten an den Browser auch die MTU Grösse beachtet werden. Wenn ein request die Grösse eines MTUs überschreitet, dann dauert die Übertragung länger, weil neue Pakete erstellt werden (Fragmentierung). Dies ist besonders für mobile Anwendungen interessant (kurze identifier, kurze cookies, ..). Gerade über EDGE oder gar GPRS wird eine Seite  langsam, wenn für jeden Request 2 und mehr Pakete übertragen werden müssen.
  • Gearman nutzen, um aufwändige Bearbeitungen im Hintergrund zu starten. Laufen zu viele Web Prozesse, die auf die Bearbeitung aufwändiger Prozesse warten, so ist der Speicher des Webservers schnell ausgelastet und das System fängt an zu swappen: dies führt fast immer zum Ausfall der Website.
  • Rasmus empfiehlt, nicht zu viele Threads im Apache zu definieren. Oftmals reicht es aus, die Anzahl der Threads auf die Anzahl der zur Verfügung stehenden Prozessoren zu setzen. Wartende Web-Prozesse werden dann durch das Netzwerk gequeued. Diese Empfehlung gilt allerdings nicht für Web-Anwendungen, die auf Backendsysteme warten müssen.
  • foreign key möglichst vermeiden, sie können deadlocks erzeugen
  • möglichst PHP 5.3 nutzen

Kurioses

Frage aus dem Publikum:Warum gibt es PHP nicht auch für den Browser?Antwort: dann gibt es noch mehr Anfragen von Endnutzern, dann ruft meine Mutter an und beschwert sich, dass eine Website nicht funktioniert. Das ist nicht, was ich möchte!

 

In PHP gibt es eine Einstellung y2k_compliance. Diese Einstellung wurde nur eingeführt, um  zur Jahrtausend Wende Anfragen der Art „Ist PHP auch 2000 fähig“ zu beantworten:  Ja, es gibt eine Einstellung dafür.

 

Diese Einstellung hat bei Cookies für Mozilla das Datum 4- statt 2-stellig übertragen, weil das in deren Doku unklar definiert war.

Folien von Rasmus Lerdorf:   http://talks.php.net/show/ezkey2011

Frank Dege

Ich bin seit mittlerweile fast 30 Jahren online (irgendwann hieß das ja mal BTX) und beschäftige mich schon fast genauso lange mit dem Thema elektronischer Handel. Schon im Rahmen meiner Diplomarbeit an der TU Berlin haben wir im Team einen Online-Shop entwickelt und automatische Test-Verfahren für Online-Anwendungen entworfen. Nach der Gründung der eigenen Firma im Jahr 2000 ging der Fokus noch stärker auf das Thema Onlineshops, hier bereits früh im Zusammenspiel mit einem ERP-System. Für silver.solutions verantworte ich federführend die Architektur und Produktstrategie unserer eigenen Onlineshop-Software silver.e-shop. Wir nutzen seit 2003 eZ Publish als Plattform für unseren Shop und ich bin immer noch absolut überzeugt davon, dass es das leistungsfähigste CMS überhaupt ist. Das sagen andere über Frank: Trendforscher /// immer neugierig auf neue Entwicklungen /// wenn er nicht programmiert, dann tischlert er.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.