> 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 !!.)
Part of the design of specweb was to make it difficult (but not imposible) to cache the doc tree. As your ops scale up, so does the size of the doc tree. If you want to test caching use ab (apache bench) or flood :-) This ususally mean that you want a lot of memory, my borrowed test machine had 8gb.... > 3. caching the fd's would be more than sufficient (than caching the > contents). This helps avoid the disk tree traversal and the open, so yes, it would cut down on a lot of processing. > 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. I would be surprised if the stat/fstat removal would make no difference but it might be small. Any system call is a context switch which adds up. Of course.... on a suped up box here, running full out, I was seeing apache use ~4% of the cpu which says that savings in apache (user space) may not add up to any significant savings... > 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. You don't want a "busy wait state" which is what you would need with ewouldblock..... chews up lots of cpu time that someone else might want. Poll is a better general solution to the problem which is why apache does it. Dave
