Re: [PATCH] mod_cache fixes: #6

2004-08-03 Thread Ian Holsman
Justin Erenkrantz wrote:
--On Monday, August 2, 2004 11:44 AM -0400 Bill Stoddard 
[EMAIL PROTECTED] wrote:

These are debug messages so not sure why they are a problem.
+0

The logging code is expensive to call for every request like that as 
many times as it does.  IMHO, there's no benefit to such a verbose log.  
More judicious use of logging would be fine, but what's there now is 
inappropriate. -- justin

In mod-proxy they use a macro called 'DEBUGGING' and if-def all the 
really verbose log messages with that.. maybe you should apply this here?


Re: [PATCH] mod_cache fixes: #6

2004-08-02 Thread Bill Stoddard
Justin Erenkrantz wrote:
--On Sunday, August 1, 2004 11:25 AM -0400 Bill Stoddard 
[EMAIL PROTECTED] wrote:

Too many changes in one patch. Break this up into multiple consumable 
in 15
minute patches and I'll review them.

* modules/experimental/mod_cache.c: Reduce logging in mainline case.
These are debug messages so not sure why they are a problem.
+0
Bill


Re: [PATCH] mod_cache fixes: #6

2004-08-02 Thread Graham Leggett
Bill Stoddard wrote:
* modules/experimental/mod_cache.c: Reduce logging in mainline case.

These are debug messages so not sure why they are a problem.
While mod_cache is experimental, it may help to have more logging rather 
than less. Are the logging functions that much of a performance problem 
when they do not apply? (ie in the case where the logging statement is 
DEBUG but the system is set to WARN, ie no log line).

Regards,
Graham
--


smime.p7s
Description: S/MIME Cryptographic Signature


Re: [PATCH] mod_cache fixes: #6

2004-08-02 Thread Jeff Trawick
On Mon, 02 Aug 2004 18:13:09 +0200, Graham Leggett [EMAIL PROTECTED] wrote:
 Bill Stoddard wrote:
 
  * modules/experimental/mod_cache.c: Reduce logging in mainline case.
 
  These are debug messages so not sure why they are a problem.
 
 While mod_cache is experimental, it may help to have more logging rather
 than less. Are the logging functions that much of a performance problem
 when they do not apply? (ie in the case where the logging statement is
 DEBUG but the system is set to WARN, ie no log line).

at the least, it would be useful to reduce the logging from two lines
to one line
(zap the first message, move the second message to where the first
message is now)


Re: [PATCH] mod_cache fixes: #6

2004-08-02 Thread Justin Erenkrantz
--On Monday, August 2, 2004 11:44 AM -0400 Bill Stoddard [EMAIL PROTECTED] 
wrote:

These are debug messages so not sure why they are a problem.
+0
The logging code is expensive to call for every request like that as many 
times as it does.  IMHO, there's no benefit to such a verbose log.  More 
judicious use of logging would be fine, but what's there now is inappropriate. 
-- justin


[PATCH] mod_cache fixes: #6

2004-08-01 Thread Justin Erenkrantz
--On Sunday, August 1, 2004 11:25 AM -0400 Bill Stoddard [EMAIL PROTECTED] 
wrote:

Too many changes in one patch. Break this up into multiple consumable in 15
minute patches and I'll review them.
* modules/experimental/mod_cache.c: Reduce logging in mainline case.
Index: modules/experimental/mod_cache.c
===
RCS file: /home/cvs/httpd-2.0/modules/experimental/mod_cache.c,v
retrieving revision 1.83
diff -u -r1.83 mod_cache.c
--- modules/experimental/mod_cache.c25 May 2004 18:01:02 -  1.83
+++ modules/experimental/mod_cache.c1 Aug 2004 08:24:52 -
@@ -327,17 +257,12 @@
return ap_pass_brigade(f-next, bb);
}
-ap_log_error(APLOG_MARK, APLOG_DEBUG, APR_SUCCESS, r-server,
- cache: running CACHE_OUT filter);
-
/* cache_read_entity_headers() was called in cache_select_url() */
cache_read_entity_body(cache-handle, r-pool, bb);
/* This filter is done once it has served up its content */
ap_remove_output_filter(f);
-ap_log_error(APLOG_MARK, APLOG_DEBUG, APR_SUCCESS, r-server,
- cache: serving %s, r-uri);
return ap_pass_brigade(f-next, bb);
}