php concurrent requests jammed?

Question

I have got an PHP application running a report and firing off about 1 million SQL queries to SQL server within 90 seconds. During the period of time no one else can use this web-based application - the egg timer is rolling but nothing loads until the report is timed out or completed. I tested this problem in an isolated environment with just myself in there, ran the report in a browser, then any actions from other browser windows to this application site hung.

Some details about the testing environment:

Windows 2008 R2 x64 - IIS 7.5 - PHP 5.3.8 via FastCGI 
Windows 2008 R2 x64 - SQL Server 2008 R2 x64

FastCGI settings in IIS:

Instance MaxRequests = 200
Max Instances = 16
Activity Timeout = 70
Idle Timeout = 300
Queue Length = 1000
Rapid Fails PerMin = 10
Request Timeout = 90

Each of the SQL requests completes less than 60ms on the SQL server side. CPU loads of both of the Web server and the SQL server are less than 10%. The Web server has 16GB RAM and about 60% RAM are available when running the report.

It seems that, PHP's been firing off too many requests to the SQL server and becoming too busy to handle other requests. If this is the case then there should be something I can tweak to make PHP handle more concurrent requests.

Does anyone know? Please help!

Answer 1

I'll just stab in the dark here and assume it's due to session locking.

When you use the standard session handler that comes with PHP, it makes sure that your session files cannot be corrupted by using (advisory) write locks throughout the course of your script's execution (unless session_write_close() is called earlier).

Other scripts that try to access the same session (your browser would pass the same cookie value) will wait for the lock to get released, as long as it takes.

You can verify this by using two completely different browsers to simulate two users (one runs the report, the other accesses the site). If that works, you're pretty sure it's due to session locking.

This shouldn't be a problem, because you will know when you're running a report, but if this might cause issues nonetheless you can consider two things:

1. don't start a session for the report script (but this also means unauthorized users could try to run your report script)
2. close the session before your grunt work starts, by using session_write_close() after you have verified the user's identity.