PHPGangsta - Der praktische PHP Blog

Ich möchte mir den aktuellen Stand von PHP 7 anschauen (Stand 20. Januar 2015), und habe dazu im letzten Blogartikel gezeigt wie man PHP 7 direkt aus dem Git-Repository selbst kompiliert. Ich habe nun also PHP 7 zur Verfügung:

$ sapi/cli/php -v
PHP 7.0.0-dev (cli) (built: Jan 20 2015 23:13:58)
Copyright (c) 1997-2015 The PHP Group
Zend Engine v3.0.0-dev, Copyright (c) 1998-2015 Zend Technologies

Vergleichen werde ich mit der aktuell unter Ubuntu 14.04 LTS verfügbaren Version PHP 5.5.9:

$ php -v
PHP 5.5.9-1ubuntu4.5 (cli) (built: Oct 29 2014 11:59:10)
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2014 Zend Technologies
with Zend OPcache v7.0.3, Copyright (c) 1999-2014, by Zend Technologies

Da die eine Version selbst kompiliert ist und die andere von Ubuntu stammt sind sie in diesem Fall nicht ideal für einen Vergleich nutzbar, aber auf ein paar Bytes oder Prozente soll es mir nicht ankommen.

PHP 7 hat in diesem Fall keinen OPcache aktiviert, aber den benötige ich für meine Tests auf der Kommandozeile (CLI) nicht. Möchte man PHP via Webserver (PHP-FPM usw.) nutzen sollte man darauf achten den OPcache per php.ini zu aktivieren, um vergleichbare Ergebnisse zu bekommen.

Folgendes kleines Testscript werde ich mit beiden Versionen laufen lassen:

<?php

$a = array();
for ($i=1; $i<2000000; $i++) {
    $a[] = rand(100000000, 999999999);
}

echo "not real: ".(memory_get_peak_usage(false)/1024/1024)." MiB\n";
echo "real: ".(memory_get_peak_usage(true)/1024/1024)." MiB\n";

Und hier sind die jeweiligen Ergebnisse:

$ time php arraytest.php
not real: 275.61262512207 MiB
real: 276 MiB

real    0m1.119s
user    0m0.763s
sys     0m0.190s

$ $ time sapi/cli/php arraytest.php
not real: 96.334381103516 MiB
real: 98 MiB

real    0m0.414s
user    0m0.290s
sys     0m0.068s

Ui ui ui! Mit PHP 7 reduziert sich der Arbeitsspeicherverbrauch bei diesem Testarray (2.000.000 Zahlen als Values) um satte 65%!

Weniger Arbeitsspeicherverbrauch heißt nicht nur dass „mehr PHP“ auf einem Server laufen kann, weniger Arbeitsspeicher heißt auch dass weniger Daten im Arbeitsspeicher abgelegt werden müssen, und weniger daraus gelesen werden muss, es impliziert also automatisch auch einen Performance-Boost. Wie man an den Laufzeiten erkennen kann ist PHP 7 auch ungefähr 3 Mal so schnell!

In richtigen Applikationen wie WordPress oder Typo3 usw. ist der Unterschied nicht ganz so groß, da spricht man von ungefähr 50% bis 110% mehr Laufzeit-Performance. Denn bei größeren Applikationen wird auch viel Zeit beim Warten auf die Datenbank verbraucht, und Warten ist genauso langsam in PHP 5.5 wie in PHP 7 😉

All diese Verbesserungen sind darauf zurückzuführen wie PHP intern Variablen und Arrays organisiert, den sogenannten ZVALs und Hashtables. Die detaillierten Informationen über die Änderungen an der Hashtable-Implementation von PHP 7 sollte man sich mal zu Gemüte führen.

Edit: Auf Wunsch habe ich auch noch PHP 5.6 getestet, hier die Ergebnisse:

wget http://de2.php.net/get/php-5.6.5.tar.gz/from/this/mirror
mv mirror php-5.6.5.tar.gz
tar -xzvf php-5.6.5.tar.gz
cd php-5.6.5/
./configure --prefix=/usr/local/php-5.6.5 --with-zlib --with-config-file-path=/usr/local/php-5.6.5/etc --enable-mbstring --with-mysql --with-mysqli --with-pdo-mysql --enable-zip --with-imap --with-kerberos --with-imap-ssl --with-openssl --with-jpeg-dir --with-gd --with-gettext --with-freetype-dir --enable-ftp --with-pspell --with-curl
make

$ sapi/cli/php -v
PHP 5.6.5 (cli) (built: Jan 23 2015 00:46:40)
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2014 Zend Technologies

$ time sapi/cli/php -d memory_limit=512M arraytest.php
not real: 275.61260223389 MiB
real: 276 MiB

real    0m1.023s
user    0m0.663s
sys     0m0.170s

PHP 5.6 ist also leicht schneller als PHP 5.5, aber zu PHP 7 ist es immer noch ein richtig großer Unterschied.

Vorausschauendes oder defensives Programmieren wird häufig vernachlässigt. Man geht allzu häufig davon aus, dass die Umgebung immer die selbe ist und wenn es einmal funktioniert, dann funktioniert es immer. Zum defensiven Programmieren gehört aber nicht nur, alle möglichen Fälle von Parametern abzufangen die jemand in eine Methode reinstopfen könnte, sondern auch die Prüfung der Webservereigenschaften. Denn wer weiß, ob das Projekt in einigen Monaten oder Jahren nicht auf einen anderen Webserver (z.B. IIS -> Apache) umgezogen wird, oder bei der Installation einer neuen PHP-Version vergessen wurde, die php.ini korrekt anzupassen.

Häufig gibt es aus diesem Grund in einem Initialisierungsscript oder einer Bootstrap-Datei Prüfungen zur verwendeten ZendFramework-Version, PHP-Version, register_globals, magic_quotes_gpc, memory_limit usw. Diese sind recht einfach zu schreiben (häufig Dreizeiler), und ich möchte hier noch eine weitere kleine Prüfung vorstellen die sicherlich die wenigsten haben.

Es geht um das Memory-Limit, also den maximalen Speicherverbrauch eines PHP-Scriptes. Diesen kann man auf 3 verschiedene Arten setzen:
Weiterlesen »