Messages in this thread | | | Date | Wed, 9 Jul 1997 10:59:32 -0700 (PDT) | From | Alex Belits <> | Subject | Re: InfoWorld web server shootout |
| |
On Wed, 9 Jul 1997, Alan Cox wrote:
> > 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
How threads help with performance on page faults, on mmaped files or plain memory (given that use of threads doesn't decrease the number of them)? I'm probably really missing something.
> and whenever it writes a block to the log files.
That can be a problem, and I think that for a lot of other reasons logs should not be written directly in the main select loop but should use separate process to do it, connected through pipe (context switches between loop and that process don't look like a significant danger for performance).
> 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.
I can't imagine a situation in an HTTP server where it's necessary to write to the same socket from two processes simultaneously. Or you mean that socket operations in general will block if blocked or fail if nonblocked even if the socket is ready? (but then how threads will avoid that?).
> 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.
I've never looked at the boa's source, but I guess, its main weakness is always blocked open() that takes large percentage of time under high load.
> > 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)
What are advantages of having >=1 thread per cpu to having >=1 process per cpu, if any? In my server I'm switching to the model where long-lived "preforked" processes do blocking operations while "main" process has select()/(poll()?) in a loop (like it always did) and does nonblocking i/o, manages internal buffers and queues of requests and passes fds to "file i/o" processes when necessary. I don't think, file i/o processes will perfrom poorly in any conditions, especially if it's one per CPU, but main concern is what performance troubles can be expected for the main process that mostly is doing select(), then writes buffers that are waiting to be written (cached files or output from FastCGI-like processes -- and I want to add mmap()'ed files as an alternative to the cache), reads requests and does some more or less fast parsing of them. I already have all i/o (except log) in that process handled by that select(), and my assumption is that unless I'm missing some heavy-processing chunks of code, select() on everything that is waiting shouldn't cause delays compared to threads that basically will do the same thing implicitly in this model, but will introduce additional "light" context switches between themselves.
-- Alex
| |