preg match or isset causing max execution time timeout

Having a problem with a simple line of code hanging PHP

[AndrewCoulton]

I'm having a problem with a line of code in a site I maintain causing timeouts although it seems simple enough. The max_execution_time of 30 seconds is being exceeded at this line.

[2]
$AccessFE= (isset($_SESSION['AccessFE']) or (preg_match('/^AccessFEClient/',$_SERVER['HTTP_USER_AGENT']))) ? true:false;
[/2]

I know that the preg_match would be more efficient if using strpos() and I'm going to change the code to do that anyway but still, it's a fairly simple regex and I can't see why this line should stall the page?

It's not happening every time but seems to happen a few requests in a row from the same client and then not again. The Session variables aren't huge (<10 keys) so I don't think it can be the isset.

PHP is 5.2.6 running as an Apache 2.2 module on a Windows 2003 server.

Any tips would be welcome.

[coopster]

Welcome to WebmasterWorld, AndrewCoulton.

Nothing there that should be setting off execution alarms. I don't believe this line is your issue, not at first glance anyway. How about your session? Are you starting your session first? Try commenting out this line and or using an exit [php.net] right before this statement to see if your script still times out.

[AndrewCoulton]

Thanks!

The timeout is reported at line 286 (which is this one). The previous line is session_start(). Could it be that that is timing out?

I have been unable to reproduce the problem on my staging server, it only happens (and then intermittently) on the production server, so unfortunately commenting out / using exit is not really an option.

Andrew

[coopster]

Could it be that that is timing out?

I believe so. The next line is nothing, should run lightning fast and without issue. However, your server is choking on the session_start for some reason by the looks of it. I would review the logs to see what is going on. You could always set up a test subdomain on your live server too so you can play around in that sandbox without knocking your production domain offline.

[AndrewCoulton]

Thanks,

I'll have a dig around and see what's going on.

Cheers,

Andrew

[AndrewCoulton]

I had of course lighted on the symptom and not the problem. I hadn't realised that session handling was atomic and the problem was occurring when the user was downloading a file from the website and then trying to access other pages or downloads simultaneously.

The file download script was keeping a lock on the session file for the duration of the download.

I added a call to session_write_close immediately prior to the download in the download script, now it works perfectly.

Thanks for the pointer. Every day's a learning day.

Cheers,

Andrew

[coopster]

You're welcome. It's most often the end of a script that will close a session for you but there are certain times when it serves you well to call session_write_close() [php.net] when you are done making changes to session variables. You have discovered one of those occasions. Another is right before you do any redirection using the PHP header() function.

if (isset($_SESSION)) {session_write_close(); } 
header('Location: http://www.example.com/'); 
exit;