Blog - gnuheidix

Normalerweise rollt man ein Versionsupgrade erst schrittweise auf Entwicklungs-, Test- und Stagesystemen aus. Neben den notwendigen Anpassungen sind dann parallel sämtliche Test-Suites und am Ende ein manueller Systemtest zu fahren. Dies beeinträchtigt die reguläre Arbeitsgeschwindigkeit erheblich, bis das Upgrade überall durchgeführt wurde.

Continuous Integration

Wenn Continuous Integration (CI) ein Bestandteil des gelebten Softwareentwicklungsprozesses darstellt, ist es ein unverzichtbares Instrument zur Sicherstellung der Softwarequalität.

Fakt ist, dass man nur in seltenen Fällen während einer solchen Aktion die reguläre Entwicklungsarbeit einstellen kann, was zur Folge hat, dass man sich nicht leisten kann, dass das CI-System für längere Zeit nicht mit Stage- bzw. Produktionsparametern betrieben wird.

Man kann aber das CI-System so umbauen, dass es beide Laufzeitumgebungen abdeckt.

Travis CI

Mittels Travis CI kann man in wenigen Klicks ein Repository bei Github um ein vollwertiges CI-System erweitern. Man braucht lediglich eine Konfigurationsdatei im Repository hinterlegen und schon kann man seine Test-Suites dort laufen lassen. Getriggert wird ein CI-Build unter anderem bei jedem Push, wenn man es nicht explizit im Commitkommentar unterdrückt. Selbst wenn mehrere Leute nahezu gleichzeitig pushen, werden alle Builds nacheinander erstellt und man kann Probleme komfortabel zurückverfolgen.

Man kann auch wunderbar konfigurieren, welche Versionen der PHP-Laufzeitumgebung bei der Builderstellung berücksichtigt werden sollen.

Versionsunterschiede

Zu Testzwecken habe ich mir ein Github-Repository mit ein paar wenigen Tests zusammengesteckt und es auf alle aktuell von Travis-CI unterstützten PHP-Laufzeitumgebungen losgelassen. Das Ergebnis kann man in der Ausgabe eines jeden Buildjobs - 5.2, 5.3, 5.4, 5.5, HHVM 2.3 - sehen.

array_memory.php - 100.000 Arrayelemente

Es ist zu sehen, dass Speicherverbrauch und Ausführungszeit bei 5.2 im Gegensatz zu 5.3 bis 5.5 niedriger sind. 5.3 ist dort in beiden Fällen eindeutig am schlechtesten. HHVM gibt für die 100.000 Nullerelemente keinen signifikanten Speicherverbrauch aus, braucht aber knapp das Doppelte an Ausführungszeit. Für dieses triviale Beispiel hat HHVM offenbar noch nicht die notwendige Betriebstemperatur erreichen können. Den Speicherverbrauch würde ich nur mit Vorsicht genießen.

Ich vermute stark, dass bei HHVM die Speicherverwaltung effizienter als beim regulären PHP gestaltet ist, was eine echte Wohltat wäre. 100.000 Arrayelemente mit jeweils dem Integerwert 0 sind beim regulären PHP mit um die 14 MB echt eine Menge Holz. Bevor man sowas einem einem Embedded-Entwickler zeigt, sollte man in Deckung gehen.

binarytrees.php

Ich habe mich wieder mal beim Benchmarks Game bedient, um einen kleinen aber schweren Algorithmus im Bezug auf Prozessor- und Speicherlast zu haben. PHP 5.3 ist wieder der ultimative Verlierer und 5.2 steht verhältnismäßig gut da. HHVM kann seine Stärken voll ausspielen und es zeigt sich, dass bei einem genügend komplexen Algorithmus der Overhead vom JIT irrelevant wird.

Fazit

Grundlegendes Monitoring von Rahmenparametern ist beim Fahren von Tests ratsam. So kann man beispielsweise auch schnell auf einen Performanceeinbruch, verursacht durch beispielsweise ein Datenbankupgrade oder eine frisch hinzugekommene zu teure Abfrage, hingewiesen werden.

Man sieht bei PHP klar, dass dessen Featureerweiterungen von 5.2 auf 5.3 Nachteile im Ressourcenverbrauch nach sich zogen, welche man in 5.4 und 5.5 versuchte wieder zu glätten. HHVM stellt meines Erachtens für PHP langfristig gesehen die Zukunft dar.