After much frustration at pages that were randomly slow and would lock
up, I traced the time-delay to a single line of code: session_start();

I thought anyone with a similar problem might benefit from my
solution.

Most of the time this function would be very fast but occasionally it
would take more than 30 seconds. This is annoying in any case but for
a frequently updated ajax-based page, it made the whole thing
unusable.

The solution in a nutshell was to minimise the opening of session-
files for writing. This is harder than it should be, but it prevents
what seemed to be file-locking issues that caused the very long calls
to session_start().

In more detail you will need to do this:
1 - Make a file that replaces the default session-handling functions,
with the example functions on this page:
http://www.php.net/manual/en/functio...ve-handler.php,
and require_once this file at the beginning of each relevant page.
2 - Divide your program into sections where you need to write session
variables (e.g. to login or log-out) and places where you just read
them (to verify someone's logged in).
3 - Make as many sections as possible fit in the latter category in
step 2. If you need to manipulate user information while they're
logged in, don't do it in sessions, instead have a unique identifier
(such as username, user-id) in the session-variables, and keep all
other user information somewhere else (e.g. a database), which you can
look up using that session variable. This way you will not need to
modify the session variables (and therefore the session-file) once
someone is logged in.
4 - Modify the custom session functions from step 1 so that your
session-files are stored somewhere other than the default location
(read the "open" function from step 1). This way your session-files
won't be deleted or modified by other php pages which may not use the
custom-session-handling functions.
5 - Modify the session "write" function so that when you're in the
sections of your code (from step 2) where sessions variables need to
be modified, it behaves as normal, but in the other sections (where it
only needs to be read), change the write function to return success
after doing nothing. In other words, cancel the write operation when
no changes have been made. The other option to achieve the same thing
is to check if any changes have been made on each call to the write
function, rather than disabling the write completely.

In my case at least this means the ajax-call can verify the user is
logged in without the default write function getting called for every
page call. This makes the system faster and completely removed the
lock up issues I was experiencing.

Your mileage may vary.

<snip>

<snip>

Or instead of refactoring your entire code base you could:

1) switch to a database session handler - PHP does not hacve
sophisticated file locking semantics so if there is any chance of
contention you're going to run into performance problems -
particularly on Microsoft platforms

and/or

2) write your own session handler which retains a hash of the
serialized session when it's loaded. Regenerate the hash when it needs
to be written, and only write the file if the hashes are different.
Include/initialize the handler using the autoprepend ini option.

C.