|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #50410 curl extension slows down PHP
Submitted: 2009-12-08 13:25 UTC Modified: 2011-05-20 01:25 UTC
Avg. Score:4.4 ± 0.8
Reproduced:18 of 18 (100.0%)
Same Version:7 (38.9%)
Same OS:10 (55.6%)
From: procyonar at gmail dot com Assigned: pajoye (profile)
Status: Closed Package: cURL related
PHP Version: * OS: win32 only - Windows 7
Private report: No CVE-ID: None
 [2009-12-08 13:25 UTC] procyonar at gmail dot com
This is possibly the same problem as described in .  PHP 5.2.11, vanilla distribution from, without any relevant php.ini changes, slows dows to a crawl on Windows 7 Ultimate whenever php_curl.dll extension is enabled.  It happens both in cli and in apache2 versions.

Just running "php -v" (version output) takes about 5-6 seconds when curl is enabled (and a CPU usage spike).  With curl disabled, it is near instantaneous, as expected.  I haven't tested whether curl actually works.  A similar delay occurs on .php page load, etc.

WRT bug 50406, I believe curl initialization code, however complicated it might be, is not supposed to take 5 seconds all by itself.  I verified that in PHP 5.3.0 on Windows XP and PHP 5.2.11 on Gentoo Linux, just to be certain, and in both cases there was no delay.

Reproduce code:
php -v

Expected result:
<1 s execution time

Actual result:
5-6 s execution time.  A similar delay occurs whenever ANY PHP script, cli or apache2, is ran.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2010-01-06 03:00 UTC] wzed dot php at gmail dot com
I'm also having this problem, with a freshly-extracted copy of (php.ini edited to enable curl). In my case the CPU spike lasts about 2 seconds (just running php.exe -v), but that's a significant delay for someone who runs CLI scripts often.

It seems to only affect PHP 5.2.11 and 5.2.12, as I wasn't able to reproduce it with 5.2.10 using the exact same php.ini file.

Confirmed on Windows 7 and XP.
 [2010-01-06 03:23 UTC]
I don't think it happens during all requests but when you start apache (as running CLI).

Can you confirm that the slowdown happens on all requests and not only on apache start?

PHP's curl does some initialization, just like many other exts.
 [2010-01-13 02:00 UTC] wzed dot php at gmail dot com
I'm not the original reporter, but I cannot confirm that the bug affects requests when running PHP as an Apache 2.2 module, only that Apache start/restart is noticeably slower with curl enabled.

Is there more initialization code now than there was in 5.2.10? I ran a diff of /ext/curl/* between 5.2.10 and 5.2.12 and didn't see anything significant.

I just tested PHP 5.3.1 and sadly the bug exists there too. :(

(I'm calling it a bug because the cause of the delay is still unknown)
 [2010-01-15 01:00 UTC] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
 [2010-02-18 10:31 UTC] raul dot valge at gmail dot com
I am using PHP as embedded in another Win application.
I can confirm that the issue occurs both from cli and embed sapi.

I have tried different versions and also found that the issue started 
with 5.2.11 and is present up to 5.3.1
 [2010-05-18 23:39 UTC] mailnew2ster at mail dot ru
The same thing happens on my system.
Windows 7 x86, PHP 5.3 (5.3.2) VC9 x86 Thread Safe (2010-Mar-04 20:11:10)

After some debugging of php I found out that the RAND_screen() function in 
libeay32.dll is responsible for slowing down the execution.
I've patched the function out, and it really became fast again. I don't use SSL 
stuff so I don't care how this affects security.

The patch is 0xE8 -> 0xC3 on offset 0x0003EE10, you can use it as a temporary 
solution (patch it with any hex editor).

 [2010-05-25 00:56 UTC] 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?
 [2010-05-25 01:29 UTC]
-Status: No Feedback +Status: Feedback
 [2010-05-25 01:29 UTC]
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 02:05 UTC] 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:

$ch = curl_init("");
$fp = fopen("example_homepage.txt", "w");

curl_setopt($ch, CURLOPT_FILE, $fp);
curl_setopt($ch, CURLOPT_HEADER, 0);



(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 

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 

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 02:14 UTC]
-Status: Feedback +Status: Assigned -Assigned To: +Assigned To: pajoye
 [2010-05-25 02:26 UTC] andrew at mammoth dot com dot au

Windows Explorer says the version of libeay32.dll for me which was included with 
PHP is 0.9.8k

I downloaded the sources from 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 

OpenSSL 0.9.8k:
OpenSSL 1.0.0:

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-08-23 00:23 UTC] michaelhood at gmail dot com
Still exists with the php_curl.dll bundled with 5.3.3.
 [2010-09-17 18:28 UTC] misc at themeads dot net
I've found this exists in 5.2.13. 
I tried to test 5.2.14, but find the same issue noted in 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 ... 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.
 [2010-09-17 18:58 UTC] misc at themeads dot net
Some additional data...

I happened to still have 5.2.5 and 5.2.6 around on the harddrive, I dropped the 
php_curl.dll from each into my php5.2.14 installation, and they both were snappy 
and no delay.  

I put the 5.2.13 php_curl.dll back in there, and back to the 5-7 second delay.  

Note that the delay occurs whether you're actually exercising curl functions or 
not... i.e., a simple page with only phpinfo() call will also result in the same 
slowness. So it's just the act of loading the extension (which again, lends 
credence to the "initialization" cause... but again, this simply didn't exist in 
earlier versions of the extension, so the initialization changed, and introduced 
this delay. 

The submitter of this article indicated it was observed in 5.2.11, my testing 
confirmed it's in 5.2.13 as well.  I'd be curious to see results of testing from 
5.2.6 thru 5.2.11 to see where this delay was introduced, but unfortunately 
don't have copies of php in all those versions.
 [2010-09-17 21:37 UTC]
-PHP Version: 5.2.11 +PHP Version: *
 [2010-09-17 21:37 UTC]
The problem has been diagnosed, however it is not sure yet how and when it can be fixed. See the other comments for the details.
 [2010-12-03 00:14 UTC]
-Status: Assigned +Status: Closed
 [2010-12-03 00:14 UTC]
Fixed in 5.3.4RC2, it will be present in 5.3 final.
 [2010-12-13 12:41 UTC] beta dot tests at hotmail dot com
On the binaries and sources releases for windows i hope that this PHP 5.3 (5.3.4) isnt the final relese
because i once i install the cURL is see a delay of at least 700ms to 1020ms, on windows xp 32bit using FastCGI
 [2010-12-20 00:47 UTC] tanguy dot pruvot at gmail dot com
Please reopen this issue...

"php -m" with php_curl : 3 seconds on a SSD disk
"php -m" without curl : instant output

Please read the previous answers, seems related to libeay32 ...
 [2011-04-11 05:29 UTC] threedigitnumber at gmail dot com
Still not solved with 5.36.

In CLI Mode with curl: php -v takes 1.15 seconds.
without curl: php -v takes 0.125 seconds.
 [2011-04-11 05:39 UTC] tanguy at pruvot dot tk
You can download the patched libeay here (work for all PHP versions) :
 [2011-04-11 07:42 UTC] tanguy at pruvot dot tk
arf, link was truncated :
 [2011-04-11 11:08 UTC]
5.3.6's does not use rand_screen anymore and any version of libcurl after this 
date either.
 [2011-04-11 11:28 UTC] threedigitnumber at gmail dot com
My tests indicate that something is still going on with 5.3.6: tanguy's ssleay fixes the issue.
 [2011-05-20 00:01 UTC] brian at access9 dot net
Win7, x64, php 5.3.6. The php cli is noticeably slower with the curl extension enabled. I can also confirm that tanguy's libeay32.dll fixes the issue.
 [2011-05-20 00:05 UTC]
-Status: Closed +Status: Feedback
 [2011-05-20 00:05 UTC]
Please try using this snapshot:
For Windows:

 [2011-05-20 00:33 UTC] tanguy dot pruvot at gmail dot com
Thanks, will check

Here is my last way to fix it (if openssl is already enabled in php)

PHP 5.3.6 VC9 x86 module without SSL Library Init
------------------------------------------------- - 06 May 2011

The curl module slow down PHP init on Windows since PHP 5.2

The docs might be a bit sparse in this ares, yes. But the SSL bit should be set 
unless you have initialized the OpenSSL library already in some other way.

And in fact the openssl module already do library init, so if loaded, this patch 
should not impact security


It is possible to fix that in extension code, in interface.c :

by replacing CURL_GLOBAL_SSL by CURL_GLOBAL_WIN32... 

	if (curl_global_init(CURL_GLOBAL_WIN32) != CURLE_OK) {
		return FAILURE;

Related discussion :
 [2011-05-20 00:49 UTC]
Simply try a snapshot, I double check and no call are done to Rand_Screen &co (so 
it is in libcurl latest release).
 [2011-05-20 01:10 UTC] tanguy dot pruvot at gmail dot com
Yes, PEAR is now usable with this version. 

Thanks, finally.. almost 2 years since first bug report...
 [2011-05-20 01:25 UTC]
-Status: Feedback +Status: Closed
 [2011-05-20 01:25 UTC]
It was already fixed in some of the 5.3.5 releases and reintroduce in 5.3.6. Also 
the bug was not in PHP but libcurl (fixed there too).
 [2011-12-18 19:19 UTC] ed at tablemaker dot net
Where do I download the fix? (Or was this "closed, not fixed"?)
PHP Copyright © 2001-2023 The PHP Group
All rights reserved.
Last updated: Tue Dec 05 03:01:26 2023 UTC