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:[EMAIL PROTECTED] >Sent: Tuesday, January 28, 2003 11:05 AM >To: [EMAIL PROTECTED] >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 >
