RE: strace of SPECWeb99 static workload

[Bill Stoddard <bi...@wstoddard.com>]

> Here is an strace of the static portion of the SPECWeb99 benchmark.
>
> http://www.apache.org/~gregames/strace.spec_static
>
> This includes two keepalive connections with multiple requests on each
> connection, with Apache 2.0.43 running on a Red Hat 7.2 box.  The number
> preceding the syscall is the time delta from the start of the
> preceding syscall;
> the <number> at the end is the time spent in the syscall itself.
>
> Some observations:
>
> The disk files aren't closed until the connection terminates.  I assume we're
> using the connection pool for some file structure.  It's probably not
> a big deal
> for prefork, but for a threaded MPM it could result in a lot of open files in
> one process.
>
> There sure are a lot of gettimeofday syscalls, often with nothing between them
> that can block.

One of them is probably here (in function ap_meets_conditions). Is there any
reason we cannot use r->request_time here?


Index: http/http_protocol.c
===================================================================
RCS file: /home/cvs/httpd-2.0/modules/http/http_protocol.c,v
retrieving revision 1.462
diff -u -u -r1.462 http_protocol.c
--- http/http_protocol.c        11 Oct 2002 15:29:20 -0000      1.462
+++ http/http_protocol.c        29 Oct 2002 22:34:14 -0000
@@ -319,5 +319,5 @@
      * highest time resolution the HTTP specification allows.
      */
     /* XXX: we should define a "time unset" constant */
-    tmp_time = ((r->mtime != 0) ? r->mtime : apr_time_now());
+    tmp_time = ((r->mtime != 0) ? r->mtime : r->request_time);
     mtime =  apr_time_sec(tmp_time);

Re: strace of SPECWeb99 static workload

["Roy T. Fielding" <fi...@apache.org>]

> One of them is probably here (in function ap_meets_conditions). Is there 
> any
> reason we cannot use r->request_time here?

I can't tell for sure right now, but the original concern was that
dynamically generated pages that are forked into a cache (something
done by RobH for IMDB) would have a modification time after the
request time, and thus a later request for that same page (which has
not changed in the interim) would be later than the IMS time and
thus always result in a 200 instead of 304.  I don't know if that
was the same concern that motivated it here.

....Roy