Re: cvs commit: httpd-test/specweb99/specweb99-2.0 mod_specweb99.c

[Brian Pane <bp...@pacbell.net>]

gregames@apache.org wrote:

>gregames    2002/06/03 11:05:50
>
>  Modified:    specweb99/specweb99-2.0 mod_specweb99.c
>

BTW, does anyone have SPECweb results for 2.0 that they're
able to discuss?

Thanks,
--Brian

Re: cvs commit: httpd-test/specweb99/specweb99-2.0 mod_specweb99.c

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

> Brian Pane wrote:
>
> > Do you have any profile data that shows where the bottlenecks are?
>
> No, sorry.  At the moment I'm focusing on mod_specweb99.
>
> >  From recent tests with other workloads, I anticipate that the most
> > expensive operations are likely to be: reading the HTTP headers,
> > directory_walk and file_walk, and possibly mod_mime.
>
> I cannot confirm or deny at the moment.  I do see stat()s for URIs that exist
> only in <Location> containers, which can't help.
>
> The IBM Linux kernel hackers I'm working with have seen long hold/spin times on
> the "dcache_lock" in their kernel profiles, and asked about what files Apache
> was opening.  I asked if some of this might be due to stat()s as well as open()s
> but didn't get a response yet.  Anyway, I suggested they try mod_cache, which
> should cut down on both open()s and stat()s.

mod_cache will bypass directory_walk and file_walk as well. Makes a big difference on
Windows...

Bill

Re: cvs commit: httpd-test/specweb99/specweb99-2.0 mod_specweb99.c

[Greg Ames <gr...@apache.org>]

Brian Pane wrote:

> Do you have any profile data that shows where the bottlenecks are?

No, sorry.  At the moment I'm focusing on mod_specweb99.

>  From recent tests with other workloads, I anticipate that the most
> expensive operations are likely to be: reading the HTTP headers,
> directory_walk and file_walk, and possibly mod_mime.

I cannot confirm or deny at the moment.  I do see stat()s for URIs that exist
only in <Location> containers, which can't help.

The IBM Linux kernel hackers I'm working with have seen long hold/spin times on
the "dcache_lock" in their kernel profiles, and asked about what files Apache
was opening.  I asked if some of this might be due to stat()s as well as open()s
but didn't get a response yet.  Anyway, I suggested they try mod_cache, which
should cut down on both open()s and stat()s.  I should try mod_cache myself, and
change to a setup where I can get meaningful profile data.

Greg

Re: cvs commit: httpd-test/specweb99/specweb99-2.0 mod_specweb99.c

[Brian Pane <bp...@pacbell.net>]

Greg Ames wrote:

>But I can mention that my very unofficial mini-SPECweb99 runs with the client
>and server both on my ThinkPad with 100% "standard dynamic GETs"* show that
>prefork is the fastest, worker is about 1% slower, and leader is about another
>1.5% slower.  This is a noticeable improvement from when I started on specweb -
>worker was maybe 10% slower at that time, and leader had a compile error.  If I
>were running the client & server on separate boxes, the differences would
>probably be larger.
>

That's good news.  We can probably remove leader and threadpool
soon.  The current worker code contains basically all of the useful
optimizations from the experimental MPMs.

Do you have any profile data that shows where the bottlenecks are?
 From recent tests with other workloads, I anticipate that the most
expensive operations are likely to be: reading the HTTP headers,
directory_walk and file_walk, and possibly mod_mime.

--Brian

Re: cvs commit: httpd-test/specweb99/specweb99-2.0 mod_specweb99.c

[Greg Ames <gr...@apache.org>]

Brian Pane wrote:
> 
> gregames@apache.org wrote:
> 
> >gregames    2002/06/03 11:05:50
> >
> >  Modified:    specweb99/specweb99-2.0 mod_specweb99.c
> >
> 
> BTW, does anyone have SPECweb results for 2.0 that they're
> able to discuss?

Not that can be published according to the SPEC rules, or are worth publishing
for that matter.  You have to run the thing for a really long time to meet the
rules, and of course the server machine becomes a basket case if you give it
enough workload.  So I cut the run time parameters way down to maintain my
sanity while doing development, which invalidates the results.

But I can mention that my very unofficial mini-SPECweb99 runs with the client
and server both on my ThinkPad with 100% "standard dynamic GETs"* show that
prefork is the fastest, worker is about 1% slower, and leader is about another
1.5% slower.  This is a noticeable improvement from when I started on specweb -
worker was maybe 10% slower at that time, and leader had a compile error.  If I
were running the client & server on separate boxes, the differences would
probably be larger.

Greg

* the standard dynamic GETs wrap a few lines of dynamically generated html
around a static file.  These make up 12.5% of the official SPECweb99 workload;
70% is pure static requests; the remainder consists of more CPU intensive types
of dynamic requests.