On Mon, Jun 18, 2001 at 02:29:18PM +0800, Trevor Phillips wrote:
>Gunther Birznieks wrote:
[>>Trevor wrote:]
>>Yeah, just use the mod_proxy model and then proxy to different mod_perl
>>backend servers based on the URL itself.
>Isn't this pretty much what I said is *a* solution?
Yes, and the only one.
>>>I suppose I could do this now by having a front-end proxy, and mini-Apache
>>>configs for each "group" I want, but that seems to be going too far (at this
>>>stage), especially if the functionality already exists to do this within the
>>>one server.
> To me, this isn't very ideal. Even sharing most of an apache configuration
> file, what is the overhead of running a separate server? And can multiple
> Apache servers share writing to the same log files?
No. The way the multiple process model that apache uses works because of
the way that sockets work:
Parent process runs as root, calls:
socket() (create the socket)
bind() (bind to our local sockaddr_in structure - ip/port)
listen() (set the socket to listen mode)
now, normally, it would then call accept() to sit there and block for while
it waits for a connection to be made. Instead what it does is rather more
cunning.
It fork()s (several times) to create the children, and immediately setuid()s
to drop its root privs. However, the bit that needs the root privs is the
bind() call above, and because of the way that fork() works, we inherit the
socket from the parent.
These *children* then call accept(). And they all block.
When a connection comes in on that socket, whichever is currently in the
schedule queue will return from the accept() system call, and handle the
request. It is, however, up to the kernel, which one calls accept().
accept() returns a *new* file descriptor, which is the one for the *stream*
(as opposed to the socket).
Obviously, if your modperl is URL dependent, then you can't determine what
URL they are going to ask for at the time you have to call accept. The only
alternative way of doing what you're asking for is to use file descriptor
passing, which is still about *the* topmost unportable bit of UNIX. :-(
It is also quite complicated to get right.
>It also doesn't help if I have dozens of possible groupings - running dozens of
>slightly different Apache's doesn't seem a clean solution. Hence me asking if
>it was possible within the one Apache server to prioritise the allocation to
>specific daemons, based on some criteria, which would be a more efficient and
>dynamic solution, if it's possible.
It isn't, because otherwise there'd be even more context-switching, (which is
slow). The clean solution, in this case, would be to have the one apache that
actually accepts, does a bit of work on the URL, and then delegates to
children (probably by passing the fd), but then you still have to do rather
too much work on the URL before you can do anything about it.
It isn't as unclean as you might think, though.
Hope this helps
MBM
--
Matthew Byng-Maddick <[EMAIL PROTECTED]> http://colondot.net/
