Srv | PID | Acc | M | CPU | SS | Req | Conn | Child | Slot | Client | VHost | Request |
---|---|---|---|---|---|---|---|---|---|---|---|---|
0-0 | 808 | 0/11/11 | W | 0.39 | 6570 | 0 | 0.0 | 0.59 | 0.59 | 64.208.172.177 | mydomain.com | GET /more.php?pid=25&PHPSESSID=c9d65dd1e729dfdddffebc5062d13878 |
1-0 | 4876 | 0/11/45 | W | 0.21 | 1516 | 0 | 0.0 | 0.41 | 0.79 | 64.208.172.177 | mydomain.com | GET /comments.php?wid=1126&PHPSESSID=a4b917d6f7a2ec3c6da2058f51 |
2-0 | 3486 | 0/19/42 | W | 1.39 | 1047 | 0 | 0.0 | 0.85 | 1.39 | 64.208.172.177 | mydomain.com | GET /comments.php?wid=1133&PHPSESSID=a4b917d6f7a2ec3c6da2058f51 |
3-0 | 3517 | 0/1/22 | W | 0.30 | 9012 | 0 | 0.0 | 0.01 | 1.01 | 64.208.172.177 | mydomain.com | GET /index.php?PHPSESSID=c9d65dd1e729dfdddffebc5062d13878 HTTP/ |
4-0 | 3518 | 0/2/17 | W | 0.27 | 7607 | 0 | 0.0 | 0.02 | 0.30 | 64.208.172.177 | mydomain.com | GET /more.php?pid=9&PHPSESSID=c9d65dd1e729dfdddffebc5062d13878 |
5-0 | 2994 | 0/7/17 | W | 1.35 | 6195 | 0 | 0.0 | 0.21 | 0.71 | 64.208.172.177 | mydomain.com | GET /more.php?pid=29&PHPSESSID=c9d65dd1e729dfdddffebc5062d13878 |
6-0 | 900 | 0/50/50 | W | 1.81 | 5789 | 0 | 0.0 | 1.04 | 1.04 | 64.208.172.177 | mydomain.com | GET /more.php?pid=36&PHPSESSID=c9d65dd1e729dfdddffebc5062d13878 |
7-0 | 3519 | 0/13/34 | W | 0.47 | 3859 | 0 | 0.0 | 0.15 | 0.48 | 64.208.172.177 | mydomain.com | GET /detail.php?pid=41&PHPSESSID=a4b917d6f7a2ec3c6da2058f51df87 |
Srv | Child Server number - generation |
---|---|
PID | OS process ID |
Acc | Number of accesses this connection / this child / this slot |
M | Mode of operation |
CPU | CPU usage, number of seconds |
SS | Seconds since beginning of most recent request |
Req | Milliseconds required to process most recent request |
Conn | Kilobytes transferred this connection |
Child | Megabytes transferred this child |
Slot | Total megabytes transferred this slot |
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