httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Querna <c...@force-elite.com>
Subject Re: Proposal: Increase request in worker_score
Date Sat, 20 Oct 2007 17:56:56 GMT
+1 to 192 or 256.

This hasn't been changed since (pre?) 1.3 days.  Computers have more
memory since then, so this completely makes sense.

-Paul

Niklas Edmundsson wrote:
> 
> Hi all!
> 
> We've been annoyed by the fact that the status page as served by
> mod_status only shows the first 64 bytes of the current requests for a
> couple of years now.
> 
> We know that it's only meant to be a hint, not the complete request in
> all conditions, but the problem is that 64 bytes is just too short to be
> useful in a lot of cases. When using httpd for serving files on a FTP
> server you usually see the directory and the first characters of the
> filename, very annoying.
> 
> Locally we've been running with a patch[1] to increase the size from 64
> bytes to 192 bytes for a while now (since httpd 2.2.4 was released) with
> no ill effects. Admittedly, our servers are configured to MaxClients
> 6000 so they don't see the insane amount of simultaneous accesses as
> some bigger configurations out there.
> 
> However, as a useful improvement we would like to propose that the
> request entry in worker_score is increased from 64 bytes to 128 bytes.
> This would cover most cases we've seen of missing just a couple of
> characters in mod_status to be able to determine which file is being
> accessed...
> 
> In terms of memory footprint it would mean the following:
> 
> sizeof(worker_score) on:
> 32bit Linux (Ubuntu 6.06) from 224 bytes to 288 bytes
> 64bit Linux (Ubuntu 7.04) from 264 bytes to 328 bytes
> 
> Summing this up for a server configured for MaxClients 20000 it would mean:
> 32bit from 4375kB to 5625kB
> 64bit from 5156kB to 6406kB
> 
> Since we're talking about memory footprint increases in the
> megabyte-range for a server configured for 20000 connections I can't see
> that the increased memory consumption should be a problem.
> 
> To be honest though, I would really prefer having it increased to
> something like 192 or 256 bytes. 256 bytes would mean an increase of
> 3750kB for 20000 MaxClients. Not much of a big deal on modern (and
> not-so-modern) hardware IMHO.
> 
> Thoughts?
> 
> 
> [1] - our patch to increase request scoreboard size.
> --- ../dist/include/scoreboard.h        2006-07-12 05:38:44.000000000 +0200
> +++ ./include/scoreboard.h      2007-09-20 20:24:41.000000000 +0200
> @@ -125,7 +125,7 @@
>  #endif
>      apr_time_t last_used;
>      char client[32];           /* Keep 'em small... */
> -    char request[64];          /* We just want an idea... */
> +    char request[192];         /* We just want an idea... */
>      char vhost[32];            /* What virtual host is being accessed? */
>  };
> 
> 
> 
> /Nikke


Mime
View raw message