httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <>
Subject Re: select vs. threads vs. fork
Date Tue, 20 Apr 1999 06:33:28 GMT
On Mon, 19 Apr 1999 wrote:

> On Mon, 19 Apr 1999, Dean Gaudet wrote:
> > POSIX defines asynchronous i/o -- aio_read() and such.  But it's not
> > portable.  And in some places (linux for example) it's implemented via
> > threads anyhow.
> That's the I/O subsystem.  Kernel threads shouldn't affect this much...

No, I'm not talking about kernel i/o threads.  I'm talking about the
aio_foo() implementation -- it uses i/o handler threads launched in
userland.  The kernel has no idea that aio is implemented.  There are no
aio system calls. 

> Well, that's 52 megs then, with 600 children... I'd be interested in
> finding out exactly how you got it down that low.

Pretty much just follow the perf-tuning guidelines. 

> I do need to do some
> CGI on these servers, so I can't ditch mod_cgi

that's fine, it's cheap. 

> , and I need mod_rewrite for
> stopping hotlinking of images.

You could write a small module that does it.  You don't save much though
-- code is free, it's completely shared. 

> Also, I need mod_alias.  That alone seems
> to make for hefty children.  When I check the output of free I see this:

Nope code is free. 

As is most everything you put into your http.conf file. 

What costs you are directives that generate run-time memory needs. 

Such as a bunch of <Directory>/etc containers.  Minimize the number of
those which can apply to each URL -- factor everything down to the lowest

>              total       used       free     shared    buffers     cached
> Mem:        386368     366936      19432     270896      45704     137808
> -/+ buffers/cache:     183424     202944
> Swap:       130748        408     130340

Look at "ps amx".  The system-wide numbers aren't decipherable. 

> Well, enlighten me... I'm just looking at empirical results here.  Would
> it be possible to have a select server process that handles only static
> content, and has the file descriptors for static content thrown over to it
> by the rest of the children?  That would get the best of both worlds, I
> think.

Descriptor passing is expensive. 

Make it multithreaded, and have a single thread which does the select
thing for static responses.  I posted about this last week or so... it's
an older idea than that, I forget whose it is originally.

(I suppose I sound like a broken record... which is a sign I should either
shut up, or get back to writing code for apache or something.) 


View raw message