session_start() is slow

[jqp]

We have an internal web application with up to 50 users at once.  We've run across a particular case where session_start() is slow.

 

For example,

$start = microtime(true);
session_start();
$end = microtime(true);
echo $end - $start;

 

That alone will take up to 1 minute sometimes.

 

We're using the built-in session handler (files).  This problem still happens even after clearing files out of the session save directory.  There is plenty of room on disk.  The server is a Debian server running PHP 5.2.  We're tried changing our session save directory to point to a RAM disk to rule out file seek time.  We rarely have more than 32MB of session data at any given time.  When a user has this problem, the session data is very small - a total of about 10 short strings. 

 

The problem occurs most often with one particular user, and I don't have an explanation for that.  Maybe she loads this particular page more often that others, but that's unlikely.  It's pretty random, and it happens to a few other users, but one user (i.e. one machine) is by far the most common.

 

This happens after the user is logged in - the session cookie is already set.  So, I don't think it has anything to do with generating the session id.

 

Any known reasons why session_start() by itself can take that long?

[PFMaBiSmAd]

I believe I have seen some information about this (in the php manual or the user contributed notes in the php manual) and it has to do with session file locking (on some operating systems) when a page contains more than one reference to a session, such as when the page and content (iframe, images, external css/javascript) on that page use the session to make sure someone is logged in...

 

I don't know the solution, but this gives you a possible starting place to search for one.

[discomatt]

Yeah, try a basic database-driven session handler ( there's at least one in the user contrib here http://php.net/session_set_save_handler ) and see if the problem continues.

[jqp]

I believe I have seen some information about this (in the php manual or the user contributed notes in the php manual) and it has to do with session file locking (on some operating systems) when a page contains more than one reference to a session, such as when the page and content (iframe, images, external css/javascript) on that page use the session to make sure someone is logged in...

 

I don't know the solution, but this gives you a possible starting place to search for one.

 

You're absolutely right, and you made our day.  It has nothing to with iframes or anything, but it's a matter of procedure.

 

Our users will commonly pull up a certain report, which takes a while, and also pull up an "edit customer" screen while that report is loading.  Apparently one particular user is doing this most often - click on "Edit Customer" while waiting for the report to load.  Since the report has the session file locked, the other pages  that call session_start() won't load.

 

Makes perfect sense and fixes the issue:  if you're doing a lot of processing (and not writing session data) get the session data, validate login, and call session_write_close before doing the heavy lifting.

 

Thanks a bunch.  This should have been obvious sooner, and you're right - it's noted in the user comments in the manual.