httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mladen Turk" <mt...@mappingsoft.com>
Subject RE: [PATCH] apr_table WAS: What to do about tables?
Date Mon, 12 Nov 2001 17:39:24 GMT


> -----Original Message-----
> From: Brian Pane [mailto:bpane@pacbell.net]
> Sent: Sunday, November 11, 2001 8:15 PM
> To: dev@httpd.apache.org
> Subject: Re: [PATCH] apr_table WAS: What to do about tables?
>
> My +1 would be non-binding, but IMHO it makes sense to keep
> optimizing your new version. With the changes to make
> apr_table_elts return const (my patch and Justin's update
> to it), it will be possible to drop in an index-based
> implementation of tables in the future without breaking
> backward compatibility.
>
> Based on this latest set of benchmarks, my suggestion is:
>   * Tune the index code until the sequential set and
>     random get cases can outperform the old code.  (These
>     are both common cases in Apache.)
>   * Then plug the new code into a copy of the httpd to
>     see the effect on overall performance.
>

Here is the drop-in replacement for apr_table that uses hash indexes to
table entries.

I've tested the code to the current httpd from cvs.
Well, the performance gain isn't as high as I expected (or my testing
approach is wrong).

Using ab the total response is aroud 1% or more faster then original, but
the connection, processing and waiting have 16 % less values (If I
calculated that correctly).

Someone has the idea how to measure those precisely?

MT.


Mime
View raw message