CODEWITHSUNDEEP
phpapachecurl
csjpeter
csjpeter

Reputation: 1946

Why php curl uses forked apache processes and php_start_session()?

I am working on a php script which does several thousands of http calls to another server using curl. I noticed continous increasing of the number of apache processes while running a similar to the below php code:

$ch = curl_init($this->server);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_CONNECTTIMEOUT, $timeout);
curl_setopt($ch, CURLOPT_TIMEOUT, $timeout);
curl_setopt($ch, CURLOPT_HEADER, TRUE);
curl_setopt($ch, CURLINFO_HEADER_OUT, TRUE);
curl_setopt($ch, CURLOPT_HTTPHEADER, array(
        "Content-Type: application/json",
        "Content-Length: ".strlen($data)));
curl_setopt($ch, CURLOPT_POST, 1);
curl_setopt($ch, CURLOPT_POSTFIELDS, $data);
$res = curl_exec($ch);

After a while I checked some of the running apache processes using gdb and for many of them I got backtraces like this:

#0  0x00007fa1fec1d617 in flock () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007fa1fbbaf53b in ?? () from /usr/lib/apache2/modules/libphp5.so
#2  0x00007fa1fbbaf7a2 in ?? () from /usr/lib/apache2/modules/libphp5.so
#3  0x00007fa1fbbae524 in php_session_start () from /usr/lib/apache2/modules/libphp5.so
#4  0x00007fa1fbbaebb9 in ?? () from /usr/lib/apache2/modules/libphp5.so
#5  0x00007fa1fbd6fe8d in ?? () from /usr/lib/apache2/modules/libphp5.so
#6  0x00007fa1fbd209fb in execute () from /usr/lib/apache2/modules/libphp5.so
#7  0x00007fa1fbcfbf60 in zend_execute_scripts () from /usr/lib/apache2/modules/libphp5.so
#8  0x00007fa1fbca85d3 in php_execute_script () from /usr/lib/apache2/modules/libphp5.so
#9  0x00007fa1fbd8b46d in ?? () from /usr/lib/apache2/modules/libphp5.so
#10 0x00007fa1ffa12508 in ap_run_handler ()
#11 0x00007fa1ffa1297e in ap_invoke_handler ()
#12 0x00007fa1ffa21c1c in ap_internal_redirect ()
#13 0x00007fa1f9f74635 in ?? () from /usr/lib/apache2/modules/mod_rewrite.so
#14 0x00007fa1ffa12508 in ap_run_handler ()
#15 0x00007fa1ffa1297e in ap_invoke_handler ()
#16 0x00007fa1ffa225b0 in ap_process_request ()
#17 0x00007fa1ffa1f3d8 in ?? ()
#18 0x00007fa1ffa18fa8 in ap_run_process_connection ()
#19 0x00007fa1ffa27210 in ?? ()
#20 0x00007fa1ffa2797a in ?? ()
#21 0x00007fa1ffa28527 in ap_mpm_run ()
#22 0x00007fa1ff9fd4a4 in main ()

So it looks like, using curl results in starting new php session. Since I am using some legacy included php code, which does session_start() but does not use session_write_close(), I can understand that such a process can not end. So I put session_write_close() before curl_init() call, and then the number of apache processes remained low.

All the curl calls are working, all the http calls are successful, data arrives, etc.

So I ended up with several unanswered question:

Upvotes: 0

Views: 514

Answers (1)

Ulrich Thomas Gabor
Ulrich Thomas Gabor

Reputation: 6654

I don't think your encountered issues have anything to do with the usage of curl.

The default PHP configuration concerning sessions is a file-based session storage mechanism. Access to files is exclusive. This has the effect that every single session can only be used by one script at a time. If a second scripts calls session_start() with the same session id, it will block at that call, until the first script finishes its execution and closes the session file. The result would (or could) be that you may see a rise in waiting processes, especially if one tries to access the website again and again while all requests block.

The solution to this problem is to close the session handler as soon as it is not needed anymore (with session_write_close) and especially before time consuming tasks (like sending a file with readfile() or performaing long running CURL requests).

Therefore your solution seems fine to me, just the explanation went in the wrong direction.

Upvotes: 1

Related Questions