Menu
▾
▴
Re: [Astlinux-devel] PHP 5.6 EoL
|
From: Lonnie A. <li...@lo...> - 2019-08-16 19:45:11
|
Yesterday I reported some best case PHP 7 speed improvements using a PHP benchmark script. Today I made a real-world test of the web interface speed, and as probably expected, not much change... Box: Jetway NF9HG-2930, time to load Status tab with Prefs "Show NTP Time Sources" unchecked -- time curl -k https://localhost/status.php -- PHP 5.6.40 real 0m0.264s PHP 7.2.21 real 0m0.259s Since our web interface does not heavily use PHP, the system calls to gather data and lighttpd network stack plays more into the processing time. Though some special cases like the CDR Log, SQL-Data and LDAP-AB tabs should benefit from PHP 7's improved speed. Here is a "CDR Log" tab test example: -- time curl -k --user admin:secret https://localhost/admin/cdrlog.php -- PHP 5.6.40 real 0m0.122s PHP 7.2.21 real 0m0.097s Lonnie > On Aug 15, 2019, at 3:37 PM, Lonnie Abelbeck <li...@lo...> wrote: > > OK, I tried PHP 7.3.8 ... it requires pcre2 and libzip which we don't include (we use pcre and libz) > > I then tried PHP 7.2.21 ... still works with pcre and libz just fine. > > The best news is the ext/date/lib/timezonedb.h format has not changed, in fact we have offer a newer version than what comes with 7.2.21 . > > Oh, and it is faster :-) > > On an APU2: > > -------------------------------------- > | PHP BENCHMARK SCRIPT | > -------------------------------------- > Start : 2019-08-15 14:15:15 > CPU : AMD GX-412TC SOC > PHP version : 5.6.40 > Platform : Linux > -------------------------------------- > test_math : 12.422 sec. > test_stringmanipulation : 12.333 sec. > test_loops : 6.945 sec. > test_ifelse : 4.169 sec. > -------------------------------------- > Total time: : 35.869 sec. > > ... and ... > > -------------------------------------- > | PHP BENCHMARK SCRIPT | > -------------------------------------- > Start : 2019-08-15 14:26:29 > CPU : AMD GX-412TC SOC > PHP version : 7.2.21 > Platform : Linux > -------------------------------------- > test_math : 2.585 sec. > test_stringmanipulation : 3.859 sec. > test_loops : 2.145 sec. > test_ifelse : 2.180 sec. > -------------------------------------- > Total time: : 10.769 sec. > > DDG researching, most general benchmark tests show PHP 7 is 2x the speed of PHP 5.6 > > Though PHP 7.2 is bigger (both with our same custom built timezonedb.h) > > PHP 5.6.40 > -rwxr-xr-x 1 root root 3580688 Aug 12 11:35 /usr/bin/php > > PHP 7.2.21 > -rwxr-xr-x 1 root root 3921344 Aug 15 14:12 /usr/bin/php > > Note: without our custom built timezonedb.h, the 7.2.21 binary size is 4360256 > > I do like the idea of OpenSSL 1.1 support built-in without having to add a patch. > > So far, testing is going good, the can-of-worms is under control :-) > > If you can test, I committed it here: > https://github.com/astlinux-project/astlinux/commit/91892424b43818e5f78e1068c14dd05a835a3d7e > > > Lonnie > > > >> On Aug 14, 2019, at 7:12 PM, Michael Knill <mic...@ip...> wrote: >> >> +1 from me >> >> Regards >> Michael Knill >> >> From: David Kerr <da...@ke...> >> Reply to: AstLinux Developers Mailing List <ast...@li...> >> Date: Wednesday, 14 August 2019 at 2:56 am >> To: AstLinux Developers Mailing List <ast...@li...> >> Subject: Re: [Astlinux-devel] PHP 5.6 EoL >> >> This feels like something that we should create a GitHub branch for and take our time over. Since moving our source to GitHub we really have not taken advantage of its development features. We don't use branches, issues, pull requests, etc. >> >> I propose creating a branch specifically to work the can of worms. Leave Master branch stable, continue to apply fixes to it, etc. But fork a branch into which we place PHP 7 and then a small group of us can thrash on that to uncover all the worms and incrementally commit fixes for them. Once thoroughly tested we merge everything back into the master. >> >> We'll need to the same at some point for the kernel upgrade to 4.x (or, gulp, 5). >> >> David >> >> On Tue, Aug 13, 2019 at 11:25 AM Lonnie Abelbeck <li...@lo...> wrote: >>> >>> >>>> On Aug 13, 2019, at 2:50 AM, Michael Knill <mic...@ip...> wrote: >>>> >>>> Hi Devs >>>> >>>> Just wondering if/when we would be looking to go to PHP 7.x considering 5.6 was EoL at the beginning of this year? >>>> I understand that PHP 7 is much faster than 5.6 so it will make some of my busy XML apps a little better. >>> >>> Hi Michael, >>> >>> Indeed, this is a can-of-worms. >>> >>> 1) Sadly, there is no LTS version of PHP to latch on to, the PHP release cycle is to introduce a new version every year, with new bugs ... fixes for two years plus security-only fixes for a year. Rinse and repeat. >>> >>> https://www.php.net/supported-versions.php >>> >>> Our current 5.6 version was the closest to LTS they have offered. Note a LTS series is of higher quality since it is scrutinized for a longer period of time. PHP 5.6.x has had 41 x-releases, whereas PHP 7.3.x is currently at 9 x-releases. >>> >>> BTW, each new PHP release is not 100% backward compatible. >>> >>> >>> 2) Sadly, PHP includes the timezone data within the php binary rather than using the Linux /usr/share/zoneinfo data. This is extra bloat for standard 32-bit (pre-Year 2038 problem) as well it includes 64-bit transition data, more significant extra bloat. >>> >>> Bug #69652 5.5.24 -> 5.5.25 binary is 13.6 % larger >>> https://bugs.php.net/bug.php?id=69652 >>> >>> We currently work around this by compiling our own 32-bit only "timezonedb.h" using the same scripts "Derick Rethans" (the timezonedb maintainer) used. This keeps the PHP 5.6 timezone data in sync with the latest Linux zoneinfo data. >>> >>> It appears later PHP versions use the same timezonedb.h file, though some details may have changed. >>> >>> >>> 3) A jump to PHP 7.3 would no doubt introduce some backward incompatibilities with the web interface, warnings at the very least. >>> >>> >>> 4) We also include "phpLiteAdmin" which at a quick glance has some PHP 7 issues, but fixes could be cherrypicked from upstream phpLiteAdmin. >>> >>> >>> That is a summary for the can-of-worms. >>> >>> Fortunately with AstLinux, PHP is not exposed to untrusted users by default, and it is highly recommended to not expose HTTP/HTTPS to anything other than trusted endpoints ... thereby limiting PHP's security exposure. >>> >>> BTW, a historical note, Manuel Kasper's fantastic "m0n0wall" project had a PHP security exposure much like AstLinux does, and he extend PHP 4.4.9 six years beyond its EOL. >>> -- >>> m0n0wall PHP 4.3.x -> 4.4.x from years 2003 -> 2008(EOL) -> 2014 >>> -- >>> >>> At some point we will need to make a version jump of PHP, but we are currently on solid ground and somewhat uncertain how we might land if we made the jump. >>> >>> As always, open to comments. >>> >>> Lonnie >>> >>> >>> >>> _______________________________________________ >>> Astlinux-devel mailing list >>> Ast...@li... >>> https://lists.sourceforge.net/lists/listinfo/astlinux-devel >> _______________________________________________ >> Astlinux-devel mailing list >> Ast...@li... >> https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > > > _______________________________________________ > Astlinux-devel mailing list > Ast...@li... > https://lists.sourceforge.net/lists/listinfo/astlinux-devel > > |
