Bug #50410 [Com]: curl extension slows down PHP

Edit report at http://bugs.php.net/bug.php?id=50410&edit=1 ID: 50410 Comment by: misc at themeads dot net Reported by: procyonar at gmail dot com Summary: curl extension slows down PHP Status: Assigned Type: Bug Package: cURL related Operating System: win32 only - Windows 7 PHP Version: 5.2.11 Assigned To: pajoye Block user comment: N New Comment: I've found this exists in 5.2.13. I tried to test 5.2.14, but find the same issue noted in http://bugs.php.net/bug.php?id=52346 in which php_curl.dll won't load at all. I'm running Win2008 R2/IIS 7.5. What I noticed is that this exists only when running php in cgi mode, which of course spins up a separate php.exe for each request. If you run in it isapi mode, which loads php and these extensions into the IIS worker process for the site, then this doesn't occur. These observations lend credence to the theory that it's related to a delay in initialization when the php_curl.dll is loaded, as noted in http://bugs.php.net/bug.php?id=50406 ... although the answer given there of "it's slow because it initializes" and then summarily closing the bug report, is pretty worthless... why is the initialization so slow? surely this is due to something introduced to that initialization process with some revision, because php_curl.dll hasn't always had this type of delay as a result of it's cumbersome initialization process. Previous Comments: ------------------------------------------------------------------------ [2010-08-23 00:23:05] michaelhood at gmail dot com Still exists with the php_curl.dll bundled with 5.3.3. ------------------------------------------------------------------------ [2010-05-25 02:26:08] andrew at mammoth dot com dot au Hi, Windows Explorer says the version of libeay32.dll for me which was included with PHP is 0.9.8k I downloaded the sources from www.openssl.org/sources for that version and the latest 1.0.0. I've pastebin'd the rand_win.c code which has the RAND_screen() method mentioned earlier. OpenSSL 0.9.8k: http://pastebin.com/CjCt7bL3 OpenSSL 1.0.0: http://pastebin.com/yeQS1khQ Diff: http://pastebin.com/fWuyTKDC It's interesting to see the usage of MAXDELAY (1 second) and several methods within that loop referencing that delay (when added together, maybe add up to the 3-5 seconds delay people are experiencing). Even the latest OpenSSL code appears to have this problem? I've only skimmed over the diff ^ changes, perhaps they have improved/reduced the delay for Windows I'm not sure. Probably worth testing a newer libeay32.dll/php_curl module though. If you need me to test I'd be happy to, just link me to the updated files. ------------------------------------------------------------------------ [2010-05-25 02:05:55] andrew at mammoth dot com dot au Confirmed as still a problem in 5.2.13 I copied my php.ini file from c:\php\php.ini to \php\523\php.ini and updated the extension_dir directory inside the file to point to the new \php\523\ext folder. I verified this change worked by running: php -c . -v This prints: PHP 5.2.13 (cli) (built: Feb 24 2010 14:32:32) Copyright (c) 1997-2010 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2010 Zend Technologies And a delay of 5 seconds. If I rename the 523\ext\php_curl.dll and re-run the command, I get an error about a missing module as expected (verified this ext dir is being used etc). If I uncomment php_curl.dll under extensions in php.ini, the same command completes immediately. On my system at least, disabling the php_curl extension fixes the problem. Interestingly, I do not have any page load delay using curl on web pages (uisng php 5.2.11). I am using IIS with Windows 7. The example code from the php documentation page works as expected: <?php $ch = curl_init("http://www.example.com/"); $fp = fopen("example_homepage.txt", "w"); curl_setopt($ch, CURLOPT_FILE, $fp); curl_setopt($ch, CURLOPT_HEADER, 0); curl_exec($ch); curl_close($ch); fclose($fp); --- (I see an example_homepage.txt file with the html contents inside). phpinfo() also reports the CURL extension has loaded. Commenting out the php_curl extension in the ini file and restarting IIS (to refresh the php ini file) shows the expected 'Fatal error: Call to undefined function curl_init()' error. So to summarise: 1) The latest PHP version still appears to have this problem 2) The md5sum of php_curl.dll between these php versions has changed; however the included libeay32.dll file has remained the same 3) It's interesting that CURL (and even just loading a blank PHP page) runs without delay under IIS, but using the CLI causes a problem. 4) mailnew2ster at mail dot ru's comment about libeay32.dll being patched is interesting. Perhaps this is the fault of OpenSSL under Windows? Maybe libeay32.dll needs to be updated to a newer version in the PHP distribution? I found another version of this file on my computer, but using that in place of the one PHP comes with causes an 'Ordinal not found' error during PHP startup when it tries to load the curl extension. I suspect PHP/php_curl needs to be compiled/linked to the newer DLL for it to work, so I cannot test a newer libeay32.dll build on my own. It may be worth a shot finding a newer version of this library (from OpenSSL?) and compiling/linking the php_curl module against it and then testing if the extension still causes the delay with an updated libeay32.dll. ------------------------------------------------------------------------ [2010-05-25 01:29:40] pajoye@php.net can you try with 5.2.13 pls? But I very much doubt that the 5 seconds are due to the problem described in this report. ------------------------------------------------------------------------ [2010-05-25 00:56:48] andrew at mammoth dot com dot au This is STILL a problem. Windows 7 64bit here, PHP 5.2.11 php -v <takes 5 seconds> for the script to terminate Five seconds for *any* CLI operation in PHP under Windows with an out of the box PHP install. Surely this is an important enough bug to warrant someone checking into this? ------------------------------------------------------------------------ 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 http://bugs.php.net/bug.php?id=50410 -- Edit this bug report at http://bugs.php.net/bug.php?id=50410&edit=1