Bug #73412 [Nab]: url-wrappers in PHP7 terrible slow

Edit report at https://bugs.php.net/bug.php?id=73412&edit=1 ID: 73412 User updated by: spam2 at rhsoft dot net Reported by: spam2 at rhsoft dot net Summary: url-wrappers in PHP7 terrible slow Status: Not a bug Type: Bug Package: Performance problem Operating System: Linux PHP Version: 7.0.12 Block user comment: N Private report: N New Comment: how can you assume http://www.hardened-php.net/ when i lead you to https://fedoraproject.org/wiki/Changes/Harden_All_Packages and /usr/bin/hardening-check and talking about PROPER? is your php cli binary *really* PIE which is *not* the same like PIC [root@srv-rhsoft:~]$ dnf info hardening-check Letzte Prüfung auf abgelaufene Metadaten: vor 7:11:06 am Mon Oct 31 00:09:04 2016. Installierte Pakete Name : hardening-check Arch : noarch Epoch : 0 Version : 2.5 Release : 4.fc24 Größe : 37 k Paketquelle : @System Zusammenfas : Tool to check ELF for being built hardened URL : http://packages.debian.org/source/sid/hardening-wrapper Lizenz : GPLv2+ Beschreibun : hardening-check is a tool to check whether an already compiled ELF file : was built using hardening flags. : : It checks, using readelf, for these hardening characteristics: : : * Position Independent Executable : * Stack protected : * Fortify source functions : * Read-only relocations : * Immediate binding Previous Comments: ------------------------------------------------------------------------ [2016-10-31 06:04:38] rasmus@php.net I assumed you meant http://www.hardened-php.net/ My build is using PIC and doesn't show any performance issues. Do some work to figure out what is going on yourself. With such a drastic difference it should be obvious in a "perf record" profile. ------------------------------------------------------------------------ [2016-10-31 06:01:38] spam2 at rhsoft dot net > No, I test clean PHP binaries. No 3rd-party hacks when you think position independent executeable is a 3rd party hack why don't you handover the bugreport to someone who is serious instead close it? all the PHP5 builds from the last years where PIE builds too without that performance problem ------------------------------------------------------------------------ [2016-10-31 05:47:23] rasmus@php.net No, I test clean PHP binaries. No 3rd-party hacks. And like I showed with my example, there is no major performance difference between url wrappers and curl. ------------------------------------------------------------------------ [2016-10-31 05:21:24] spam2 at rhsoft dot net Hi thanks for feedback - please dont miss the part under the line - mabye that's the reason we talk about 0.647s versus 36s for jsut 50 requests here while the libcurl variant takes 29s for FIVE THOUSAND requests and that's hardly a difference between GET/HEAD (BTW: why in the world does get_headers() make GET requests while http://php.net/manual/de/function.get-headers.php don't claim that as also common sense says GET by what it does and the fact that even with <Limit GET POST> you can't disable HEAD-Requests - point is it feels like doing 1 request per second which is not far from teh truth and i have a script doing around 100000 requests which was fine with 5.x and pure file_get_contents() ____________________________________ is your PHP build a proper hardened build? i saw as example when Fedora 23 switched the whole distribution https://fedoraproject.org/wiki/Changes/Harden_All_Packages grep go magnitued slower and now with F24 it's as fast as before and still a hardened build, so i guess there was some bug in the code which made it make that way [root@srv-rhsoft:~]$ /usr/bin/hardening-check /usr/bin/php /usr/bin/php: Position Independent Executable: yes Stack protected: yes Fortify Source functions: yes (some protected functions found) Read-only relocations: yes Immediate binding: yes if that's the reason may i suggest developers only test with hardened builds because no one should run these days any non-PIE/non-FULLRELRO code except broken one which don't build proper and can't yet replaced ------------------------------------------------------------------------ [2016-10-31 01:52:19] rasmus@php.net I see a couple of issues with your sample code here. The biggest one being that you are not comparing the same things at all. get_headers(), as per the docs, uses a GET request by default. But your curl example uses a HEAD request. Obviously a HEAD request is going to be much quicker. Your php get_headers() vs. wget timing isn't valid either since obviously php cli has way more startup work to do than wget. I just wrote a quick test and I don't see a drastic difference between curl and the url wrappers on Linux. I got this output: 4.2943890094757 5.9716069698334 So yes, get_headers() is a bit slower, but certainly not orders of magnitude like you are claiming. This is my test script: <?php function curl_headers($url) { $ch = curl_init($url); curl_setopt($ch, CURLOPT_NOBODY, true); curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); curl_setopt($ch, CURLOPT_HEADER, true); $r = curl_exec($ch); curl_close($ch); return explode("\n", trim($r)); } $i=0; $start = microtime(true); while($i++<1000) { $headers = curl_headers('http://htpc/index.html'); } echo (microtime(true) - $start)."\n"; $i=0; stream_context_set_default(['http' => ['method' => 'HEAD']]); $start = microtime(true); while($i++<1000) { $headers = get_headers('http://htpc/index.html'); } echo (microtime(true) - $start)."\n"; ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=73412 -- Edit this bug report at https://bugs.php.net/bug.php?id=73412&edit=1