I'm also having this problem, with a freshly-extracted copy of php-5.2.12-Win32.zip (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.

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.

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)

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".

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

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).

Cheers!

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?

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.

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.

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.

Still exists with the php_curl.dll bundled with 5.3.3.

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.

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.

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.

Fixed in 5.3.4RC2, it will be present in 5.3 final.

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

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 ...

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.

You can download the patched libeay here (work for all PHP versions) :
http://tanguy.wdscript.fr/index.php?q=content/php-535-correctif-lenteur-au-
chargement-de-phpcurl

arf, link was truncated :
http://tanguy.tk/?q=content/php-535-correctif-lenteur-au-chargement-de-phpcurl

5.3.6's does not use rand_screen anymore and any version of libcurl after this 
date either.

My tests indicate that something is still going on with 5.3.6: tanguy's ssleay fixes the issue.

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.

Please try using this snapshot:

  http://snaps.php.net/php5.3-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/

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
-------------------------------------------------
tanguy.pruvot@gmail.com - 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

PHP_MINIT_FUNCTION(openssl)
...
SSL_library_init();


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 :
http://http://bugs.php.net/bug.php?id=53578
http://tanguy.tk/?q=content/php-535-correctif-lenteur-au-chargement-de-phpcurl 
(french)
http://osdir.com/ml/web.curl.general/2004-05/msg00068.html
http://curl.haxx.se/mail/lib-2004-06/0133.html

Simply try a snapshot, I double check and no call are done to Rand_Screen &co (so 
it is in libcurl latest release).

Yes, PEAR is now usable with this version. 

Thanks, finally.. almost 2 years since first bug report...

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).

Where do I download the fix? (Or was this "closed, not fixed"?)