On Wed, December 13, 2006 10:43 pm, Kevin Jones wrote: > What do lockf and sbwait mean? Are the processes just idling? This answer falls more under the realm of Voodoo than Debugging, but it's possible that the lockf processes are waiting on PHP to finish its locked session storage. It's very very very common to develop a web application that does this: <?php session_start(); $inputs = $_SESSION['inputs']; //very long process here with SQL etc //note that we are NOT actually reading/changing $_SESSION here ?> PHP has to keep the session file locked the whole time because you might change the data in it, and in order to avoid race conditions, it cannot allow another process to write to that particular session cache. This is not an issue, unless your IMG tags, your iframes, your Ajax-y elements and so on all are trying to utilize the same session data... At which point a single page load, instead of doing the main document, IMGages, iframes, and Ajax stuff in parallel, has to end up doing them sequentially as PHP locks, processes, and unlocks the session data for each individual request. Inserting a http://php.net/session_write_close after your last usage of $_SESSION in every script is a fairly quick and easy way to minimize your current time-window of session lock-age. Consolidating $_SESSION activity into one portion of a script, instead of scattered willy-nilly, can be a long-term task, but give significant performance boost, as I understand it. Disclosure: I'm merely parroting what has been posted to PHP lists/forums here, and have not actually had to do this (yet) for any sites. -- Some people have a "gift" link here. Know what I want? I want you to buy a CD from some starving artist. http://cdbaby.com/browse/from/lynch Yeah, I get a buck. So? --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|