Messages in this thread |  | | | From | (Alan Cox) | | Subject | Re: InfoWorld web server shootout | | Date | Wed, 9 Jul 1997 08:40:25 +0100 (BST) |
| |
> just loaded into real allocated memory and are sent using select() > and nonblocking write()s, although probably the same thing will > work well on mmap()'ed files, too. I don't use any kind of threads and
mmap means the file is sharing the disk cache and your memory. For a single task its no big deal.
> IMHO in Linux threads have no advantage over plain operations on > select()'ed descriptors, given that the time spent in request parsing and > preparing the response isn't huge compared to actual data transfer --
At very high speed they do because your single threaded task blocks briefly every page fault it takes and whenever it writes a block to the log files. You can also only be doing one write to a socket at a time in cases where memory allocation pauses might get filled by another task.
As an example on a big machine if you hit it hard enough boa becomes slower than apache because its single threaded. Now it doesn't preload pages so the effect is bigger.
> be no possible way to increase the server throughput by the use of threads > (reducing the number of context switches between processes at the price of > having context switches between threads, if I'm not mistaken, is worthless > in Linux where context switch between threads isn't much cheaper than > context switch between processes).
Both on Linux are extremely cheap, but a clone() based thread is a fair bit faster than a process switch if you are using CLONE_VM as it doesnt cause a TLB flush on a task switch. You also want one thread per cpu or more of course 8)
|  |