PHP 7.3.0 RC 4: Performanceboost und bitte testen!
Vor 3 Tagen ist der nach Plan drittletzte Release-Candidate von PHP 7.3 erschienen: RC4. Es wird noch einen RC5 und RC6 geben, bevor hoffentlich pünktlich zu Nikolaus am 06.12.2018 das finale PHP 7.3.0 GA erscheinen wird.
Es ist also höchste Zeit, dem PHP-Team dabei zu helfen, Bugs zu finden. Eigentlich sollte man das schon früher getan haben, aber besser spät als nie!
PHP 7.3 bringt erstaunliche Performanceverbesserungen im Bereich des Garbage-Collectors. Früher konnte man einiges an Performance gewinnen, indem man stellenweise den Garbage-Collector deaktiviert. Vor allem wenn mit vielen Objekten gearbeitet wird, hat das Deaktivieren einiges an Performance gebracht (teilweise >70%, siehe DomPDF oder Composer). Mit PHP 7.3 ist das nicht mehr nötig, man bekommt die Performanceverbesserungen frei Haus, man muss den GC nicht mehr deaktivieren. Gratis Performanceboost ohne eine Zeile Code zu ändern!
Selbst kompilieren
Also los, wir kompilieren PHP 7.3.0 RC4 selbst, in diesem Fall auf einem Ubuntu 18.04 Server. Damit es nicht langweilig wird, nehmen wir diverse Extensions mit dazu, ihr nehmt am besten eure, die ihr so braucht für eure Applikationen.
cd /tmp wget https://downloads.php.net/~cmb/php-7.3.0RC4.tar.gz tar -xzvf php-7.3.0RC4.tar.gz cd php-7.3.0RC4/ ./configure --prefix=/usr/local/php7.3.0RC4 --with-zlib --with-config-file-path=/usr/local/php7.3.0RC4/etc --enable-mbstring --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 make test
Falls beim configure Fehler auftreten, guckt unten in der Liste am Ende dieses Artikels, da habe ich die aufgeschrieben, die bei mir aufgetreten sind. In allen Fällen fehlten Developer-Pakete zum Kompilieren einiger Extensions.
Am Ende des „make test“-Durchlaufs der über 13.000 Tests erhaltet ihr das Ergebnis. Falls Fehler aufgetreten sind, könnt ihr den Fehlerbericht direkt an das QA-Team schicken indem ihr Y drückt und eure E-Mail-Adresse eingebt zwecks eventueller Rückfragen. Eine Liste aller fehlgeschlagenen Tests von allen Testern gibt es auf qa.php.net.
Bei mir sind beispielsweise 6 Tests fehlgeschlagen:
FAILED TEST SUMMARY --------------------------------------------------------------------- Bug #61948 (CURLOPT_COOKIEFILE '' raises open_basedir restriction) [ext/curl/tests/bug61948.phpt] Bug #72333: fwrite() on non-blocking SSL sockets doesn't work [ext/openssl/tests/bug72333.phpt] Bug #41655 (open_basedir bypass via glob()) 1/2 [ext/standard/tests/file/bug41655_1.phpt] Test glob() function: ensure no platform difference, variation 3 [ext/standard/tests/file/glob_variation5.phpt] int stream_socket_sendto ( resource $socket , string $data [, int $flags = 0 [, string $address ]] ); [ext/standard/tests/streams/stream_socket_sendto.phpt] file upload greater than 2G [sapi/cli/tests/upload_2G.phpt]
Nach „make“ kann PHP genutzt werden, beispielsweise kann man damit seine PHPUnit-Tests mal durchlaufen lassen.
$ /tmp/php-7.3.0RC4/sapi/cli/php -v PHP 7.3.0RC4 (cli) (built: Oct 27 2018 19:15:31) ( NTS ) Copyright (c) 1997-2018 The PHP Group Zend Engine v3.3.0-dev, Copyright (c) 1998-2018 Zend Technologies
Um nach den ganzen Tests wieder aufzuräumen, kann der Ordner /tmp/php-7.3.0RC4/ einfach wieder gelöscht werden. Oder wenn man es länger behalten möchte, installiert man die PHP-Version nach /usr/local/php7.3.0RC4 (siehe prefix Parameter beim configure):
sudo make install
Sollte man auf einem Testsystem machen, je nach Parametern (–with-apxs2) verändert/zerstört ihr eventuell euren laufenden Apache.
Bis zum „make test“ macht ihr auf jeden Fall nichts kaputt, und ihr könnt in Ruhe testen.
Viel Spass beim Testen, und beim Messen der Performanceboosts eurer Applikationen! 🙂
Mögliche Fehlermeldungen beim Kompilieren
Hier sind die Fehlermeldungen, die auf meinem Ubuntu 18.04 aufgetreten sind, inklusive der Lösungen:
configure: error: xml2-config not found. Please check your libxml2 installation. sudo apt-get install libxml2-dev
--------
configure: error: Cannot find OpenSSL's <evp.h> sudo apt-get install libssl-dev
--------
checking for cURL 7.15.5 or greater... configure: error: cURL version 7.15.5 or later is required to compile php with cURL support sudo apt-get install libcurl4-openssl-dev
--------
configure: error: Cannot find OpenSSL's libraries sudo apt-get install pkg-config
--------
configure: error: Cannot find zlib sudo apt-get install zlib1g-dev
--------
checking whether to enable JIS-mapped Japanese font support in GD... no If configure fails try --with-webp-dir=<DIR> configure: error: jpeglib.h not found. sudo apt-get install libjpeg-turbo8-dev
--------
configure: error: png.h not found. sudo apt-get install libpng-dev
--------
configure: error: freetype-config not found. sudo apt-get install libfreetype6-dev
--------
configure: error: utf8_mime2text() has new signature, but U8T_CANONICAL is missing. This should not happen. Check config.log for additional information. sudo apt-get install libc-client2007e-dev
--------
configure: error: Kerberos libraries not found. Check the path given to --with-kerberos (if no path is given, searches in /usr/kerberos, /usr/local and /usr ) sudo apt-get install libkrb5-dev
--------
configure: error: Cannot find pspell sudo apt-get install libpspell-dev
--------
configure: error: Please reinstall the libzip distribution sudo apt-get install libzip-dev
Hallo Michael,
vielen Dank für Deinen hilfreichen Artikel.
Mittlerweile sprechen wir ja nicht mehr von PHP 7.3, sondern befinden uns bereits in den PHP 7.4 und „beyond“ Zeiten 😉
Ich nutze derzeit eine Implementierung, die von Haus aus leider nur maximal PHP 7.2 unterstützt.
Durch Deinen Beitrag konnte ich jedoch auch PHP 7.4 kompilieren und zum Laufen bringen. Ich werde jetzt mal ordentlich testen – Gefühlt hat sogar zwischen PHP 7.2 und 7.4 die Geschwindigkeit durchaus merklich zugenommen – mag aber auch der Konfiguration von PHP-fpm liegen 😉
Gruß Dirk
DJ
21 Jan 20 at 16:52
Hallo Michael,
Ich habe als Freelncer oft Projekte und Aufträge auf PHP-Basis. Leider sind die Anpassungen durch PHP-Upgrades manchmal mit viel Aufwand verbunden. Deshalb verzcihte ich auf den gratis Performace-Boost und warte noch zu.
LG, Sabine
Sabine
25 Jan 22 at 12:31
@Sabine: Du bist noch auf PHP <= 7.2, und findest den Schritt auf 7.3 zu groß? Wie alt ist die Software? Läuft sie unter 7.2 ohne Warnings und Notices und Deprecations? Ist es "ein Gefühl" von dir, dass ein Upgrade viel Arbeit machen wird, oder hast du es geprüft mittels "php7mar", Exacat etc.? Siehe diesen Blogbeitrag für einige Tipps für einen Major-Versionssprung von PHP 5 auf 7: https://www.phpgangsta.de/applikationen-migirieren-von-php-5-6-auf-php-7-3
PHP 7.2 und selbst PHP 7.3 erhalten schon keine Sicherheitspatches mehr, siehe:
https://www.php.net/supported-versions.php
Aktuell bekommen nur 7.4, 8.0 und 8.1 Sicherheitsupdates.
Sollte deine Software gehackt werden und dadurch personenbezogene Daten (IP-Adressen, E-Mail-Adressen, etc.) geklaut werden, könnte man dir Fahrlässigkeit oder Vorsatz vorwerfen, denn laut DSGVO müssen personenbezogene Daten „nach dem Stand der Technik“ geschützt werden. Eine Software, die keine Sicherheitsupdates mehr erhält, ist nicht „Stand der Technik“.
Du solltest sowas deinen Auftraggebern dringend sagen. Und dir schriftlich bestätigen lassen, dass du sie auf diese Sicherheitsprobleme hingewiesen hast. Falls dann mal was passiert, bist du sauber raus, du hast es der Firma gesagt und sie auf das Risiko hingewiesen. Wenn sie darauf nicht hören, ist es deren Problem. Aber wenn Geschäftsführer hören dass eine Strafe von 4% des Konzernumsatzes im Raum steht, denkt hoffentlich der ein oder andere drüber nach, alle paar Jahre mal ein paar Hundert oder Tausend Euro in die Hand zu nehmen, um die Software zu aktualisieren.
Michael Kliewe
25 Jan 22 at 13:30
Ich habe mein Telefonverzeichnis https://telindex.ch auf PHP 7.3.0 upgedatet und merke leider überhaupt keine Verbesserung betr. Geschwindigkeit. Das Verzeichnis hat über eine Million Einträge.
LG, Eva
Eva
23 Apr 22 at 16:21