Had a problem the other day when trying to optimise the performance of a site that was on my companies in-house content management platform. Now the speed of the response to generate the HTML was not the issue. The issue was that all of the content managed assets were taking seconds to load in. Now this was the first site that we had that the client had included quite a lot of cm images on all there pages.
Trying to debug the issue was difficult the images them self would load in a matter of milliseconds. Using operas dragon fly feature could see that it wasn’t a bandwidth issue, and no data was been sent from the server for seconds.
Now I didn’t know it but is seems that php’s session handling is blocking on a per request basis. Kinda makes sense if you think about it, that if two requests simultaneously try and change a session variable then you would get constancy issues. So php handles this by making session_start() a blocking action and will wait for any other request to either finish or close the session using session_write_close().
For me it came down to only starting the session when necessary and closing it as son as your finished with it. As it turned out the best solution for us on the cm images was to check to see if any permissions were set on the images before seeing if we needed to start the session.
Note that this only happens if you’re using the “files” session save handler, because the PHP process locks the file. This is not necessarily true for other save handlers (i.e. “memcache”).
Thanks Olek,
Thats defiantly a point worth mentioning.
Newer versions of memcache session handling does block.
I also noticed that when trying to test AJAX queuing. Basically I was confused as to why the php app was seemingly queuing requests even though I had the AJAX manager set not to, then realized it was related to file based sessions.
I recommend going with DB or memcache based sessions.
You should be aware that you can get ugly race conditions when using custom session handler without a locking mechanism (as Olek said, locking has to be implemented in the custom session handler, as it isn’t an implicit feature of the PHP session mechanism)
Race conditions occur for all kinds of concurrent requests within the same session. Concurrent requests can emerge from some AJAX calls, but also when using frames (or iframes). Problem: 1. some requests start concurrently and read the same session data, 2. two or more of those requests change session information, 3. custom session close handler of each script writes changed session information. 4. last write wins.
Using a session handler which implements locking and starting sessions only if (and when) needed and closing them as soon as possible is IMO the only realiable (and manageable) solution.
Sebastian
Pingback: session_start is a blocking call in PHP - Rebelic /by Timan Rebel (@timanrebel)