dean gaudet wrote:
[...]
>but still, does this really work? 'cause the time used is
>r->request_time, if a request takes longer than 14 seconds or so to
>generate/serve then the logger is going to be asking for timestamps which
>are dangerously close to your cache rollover. and since you can'
On Mon, 10 Sep 2001, Brian Pane wrote:
> dean gaudet wrote:
>
> > why is there a need for 15 entries? if it's a multiprocess server then
> > there's only a need for 1 or 2 entries. if it's a multithreaded server
> > then you need to lock the cache (which you're not doing :)
>
> The whole point
dean gaudet wrote:
> why is there a need for 15 entries? if it's a multiprocess server then
> there's only a need for 1 or 2 entries. if it's a multithreaded server
> then you need to lock the cache (which you're not doing :)
The whole point of the design is to do the multithreaded cache
with
On Sunday 09 September 2001 23:51, Brian Pane wrote:
> Cliff Woolley wrote:
> >On Sun, 9 Sep 2001, Brian Pane wrote:
> >>I think putting it in APR would work. The one limitation I can think of
> >>is that adding the cache in apr_explode_localtime() itself wouldn't be a
> >>win because we'd have t
Brian Pane wrote:
> William A. Rowe, Jr. wrote:
>
>> Is this the right place to be caching, or should this become a
>> straightforward
>> optimization to apr's time.c functions? I'd think the advantages are
>> many for
>> keeping 15 current seconds in apr, and would pay off across the
>> boar
why is there a need for 15 entries? if it's a multiprocess server then
there's only a need for 1 or 2 entries. if it's a multithreaded server
then you need to lock the cache (which you're not doing :)
isn't the real win in eliminating both the divisions required by the
explode time functions an
Cliff Woolley wrote:
>On Sun, 9 Sep 2001, Brian Pane wrote:
>
>>I think putting it in APR would work. The one limitation I can think of
>>is that adding the cache in apr_explode_localtime() itself wouldn't be a
>>win because we'd have to add the overhead of a gettimeofday() call to
>>check wheth
On Sun, 9 Sep 2001, Brian Pane wrote:
> I think putting it in APR would work. The one limitation I can think of
> is that adding the cache in apr_explode_localtime() itself wouldn't be a
> win because we'd have to add the overhead of a gettimeofday() call to
> check whether the supplied time was
William A. Rowe, Jr. wrote:
>Is this the right place to be caching, or should this become a straightforward
>optimization to apr's time.c functions? I'd think the advantages are many for
>keeping 15 current seconds in apr, and would pay off across the board. Within
>apr, we can always recalcula
On Sun, 9 Sep 2001, William A. Rowe, Jr. wrote:
> Is this the right place to be caching, or should this become a
> straightforward optimization to apr's time.c functions? I'd think the
> advantages are many for keeping 15 current seconds in apr, and would
> pay off across the board. Within apr,
l, for fun.
Bill
- Original Message -
From: "Brian Pane" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, September 09, 2001 9:46 PM
Subject: [PATCH] performance patch for mod_log_config
> The call to apr_explode_localtime() in mod_log_config is one of
On Sun, 9 Sep 2001, Brian Pane wrote:
> The call to apr_explode_localtime() in mod_log_config is one of the more
> expensive operations in the httpd. This patch attempts to reduce the
> overhead by caching the result.
Looks quite reasonable... I wouldn't mind seeing this as an ap_ function,
sin
Ryan Bloom wrote:
>On Sunday 09 September 2001 19:46, Brian Pane wrote:
>
>Can we get this as a unified diff?
>
sure, here's the unified form:
Index: modules/loggers/mod_log_config.c
===
RCS file: /home/cvspublic/httpd-2.0/modules/l
On Sunday 09 September 2001 19:46, Brian Pane wrote:
Can we get this as a unified diff?
Ryan
> The call to apr_explode_localtime() in mod_log_config is one of the more
> expensive operations in the httpd. This patch attempts to reduce the
> overhead by caching the result.
The call to apr_explode_localtime() in mod_log_config is one of the more
expensive operations in the httpd. This patch attempts to reduce the
overhead by caching the result.
--Brian
Index: modules/loggers/mod_log_config.c
===
RCS
15 matches
Mail list logo
