httpd-test-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1)" <madhusudan_mathiha...@hp.com>
Subject RE: gettimeofday calls
Date Tue, 28 Jan 2003 21:09:55 GMT
I had a couple of inputs here : I was talking to our specweb person, and he
had the following views :

1. most modern day os'es cache the files, and not do a disk io for every
single file request. (duh !!.)
2. when doing writes, do a 64M block writes, instead of write to disk every
time.. (Lazy write)
3. caching the fd's would be more than sufficient (than caching the
contents). 
4. on hp-ux, eliminating the stat/fstat would not make a lot of difference..
I dont know about other os'es - but, based on his logic, since the fd for
that file is already available, fstat should not take a lot of time.

5. Another interesting question : why do we need the poll everytime ?.
Instead do a accept, and if there's no request available, accept would
return EWOULDBLOCK. For a benchmark, accept would *never* return
EWOULDBLOCK, and for a normal server, it's okay - because the server is
idle.

-Madhu

>-----Original Message-----
>From: Greg Ames [mailto:gregames@apache.org]
>Sent: Tuesday, January 28, 2003 11:05 AM
>To: test-dev@httpd.apache.org
>Subject: Re: gettimeofday calls
>
>
>Greg Ames wrote:
>> Bill Stoddard wrote:
>
>>>  Why not use mod_file_cache? 
>> 
>> On my wimpy 200MHz server, the SPEC file_set contains 5760 files and 
>> uses .8G of disk.  On more modern servers, the size of the 
>file_set goes 
>> up in proportion to the number of conforming connections you hope to 
>> push thru it, so figure 57,600 files and 8G of space on a 
>2GHz server.  
>> 8G isn't going to fit into one process's virtual memory on a 
>Pentium; 
>> caching 57,600 fd's is going to be a challenge too, as I 
>think Madhu is 
>> finding out.
>
>One way to make this easier might be to cache as many of the 
>smaller files in 
>memory as will reasonably fit, then caching the file 
>descriptors for the 
>remaining files.  If that still isn't practical, you could 
>fagettabout caching 
>the very biggest files since they will take a long time to 
>serve no matter what.
>
>On the hypothetical 2GHz server, if I cached all the class0_* 
>thru class2_* 
>(smallest) files in memory, that would eat about .8G per 
>process, leaving 14,400 
>larger class3_* files to deal with somehow.
>
>A disadvantage of caching in memory might be higher CPU usage 
>from copying + 
>checksumming data from user space to NIC buffers vs. using 
>sendfile.  That 
>probably doesn't matter for really tiny files.
>
>Greg
>

Mime
View raw message