On 2007.09.27, John Buckman <[EMAIL PROTECTED]> wrote: > Lighthttpd is *not* using the system call to send a file to a socket > (I forget the name) as this call was taken out of the Linux kernel, I > believe with 2.4. I remember reading a note about this from Linus, > that the performance for that system call was terrible, so they were > taking it out.
Hmm--I'm not sure what you're thinking of or referring to, but the common "optimization" is to use sendfile(2), which seems to be alive and well in the 2.6 tree. Sendfile requires that the data to be written come from a file descriptor. The assumption is that the program opens a file, then wants to pass it off to have it sent out another file descriptor, typically a network connection. But, what if you want to avoid disk I/O and cache that data in memory? sendfile() isn't necessarily workable, there. Perhaps you could mmap() to a fd and use that--should test the performance of such an implementation. > Based on my own experience with sending large files over tcpip, the > difference is that aolserver uses a thread-based approach vs a > lighthttpd's single-thread async approach. It might be possible to push static file processing further up the chain into the DriverThread and get better performance on larger static files--or, have one dedicated I/O thread separate from the main driver thread to handle async I/O of static assets. (I'm in favor of the latter, separate thread, just to avoid further complication of the main DriverThread.) > But really, I'm not sure aolserver's performance is really an issue > anyhow, because aolserver only slows down with large files (100mb+) > and at that point, you're completely saturating your network > connection (in my 128mb benchmark below, aolserver is sending 695mb > per second!) Right--the cry of "AOLserver isn't fast enough for static file serving" is kinda BS. If you need one single box to be able to saturate its GigE link, I think your technical requirements are questionable. :-) The bottleneck is very likely to be your upstream bandwidth to your peer before you run out of juice in AOLserver. > So, I don't see any point in worrying about improving aolserver's > plain-file-sending, at least until we get start getting 10 gigabit > network cards (!) I am concerned about your "hello world" dynamic request benchmark, though. I would have expected at least 4k req/sec--not the sub-1k req/sec you saw. I have a feeling it has to do with the default ns_pools/ns_limits settings, which naturally are NOT tuned for a 8-core CPU box. I bet with just a few minutes of tweaking and tuning, we can get between 4k-8k simple dynamic req/sec out of your hardware. -- Dossy -- Dossy Shiobara | [EMAIL PROTECTED] | http://dossy.org/ Panoptic Computer Network | http://panoptic.com/ "He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on." (p. 70) -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[EMAIL PROTECTED]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
