httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Plüm, Rüdiger, VIS <ruediger.pl...@vodafone.com>
Subject AW: [PATCH] mod_disk_cache: store/read array & table
Date Tue, 24 Jan 2006 12:46:50 GMT


> -----Ursprüngliche Nachricht-----
> Von: Ian Holsman 
> 
> 
> Brian Akins wrote:
> > This is a rather nasty patch (sorry).  Basically, it changes the way
> > arrays and tables are stored on disk.  This allows us to do a much 
> > cleaner and quicker read_array and read_table.  It cuts down 
> > significantly on the number of disk reads for header files 
> (one big one) 
> > and the number of strdup's (it used apr_table_addn, for example).
> > 
> > Bottom line is alot fewer system calls and allocations.  It 
> gives me a
> > 5% increase in mod_disk_cache across the board.
> > 
> 
> does anyone have any objections to this patch?
> 5% is a pretty nice gain imho.


To be honest I do not understand why Brian creates its own buffered
input / output reading. I think that header files are rarely larger than 4K.
And the current code already buffers 4K when APR_BUFFERED is set as a flag for
apr_file_open (which is set). So I currently cannot believe that we really
save disk io / syscalls. Of course the apr methods have more overhead for
buffering than Brians code because they are thread safe which is not needed
in this case IMHO. So I guess some cycle's are safed. OTH we tried to use apr to
abstract such things as buffered input away from the httpd code. As always
such solutions are generalized and create some overhead.

So I am currently -1 (vote not veto) on the buffering aspects of the patch.

Regarding the alternate method in safeing the arrays and tables itself
I had not have the time to dig in deeper, so I cannot give a comment on
this aspect. The only thing I understood so far is that cycles should be saved
by dumping / reading the data structures directly instead of using the
apr access methods.

Regards

Rüdiger

[..cut..]


Mime
View raw message