lkml.org 
[lkml]   [1997]   [Jul]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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


\
 
 \ /
  Last update: 2005-03-22 13:39    [W:0.059 / U:0.828 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site