> I'm writing in hopes of getting some clarification about these two
> configuration options:
>
> AcceptMulti ON
> NumConnections 1024
>
> I currently have the server configured as above since RAM is plentiful. If
> AcceptMulti were changed to OFF would the server still be able to handle a
> large load of many files with only 164 available file descriptors?
No. The AcceptMulti flag does not have any effect on whether mathopd
accepts a new connection when all connections are used up. (At the moment,
new connections are simply thrown away when this occurs. This is probably
wrong.)
A brief explanation of AcceptMulti:
When AcceptMulti is turned on, the following happens (grossly
oversimplified)
0: ... wait for incomming connections
1: accept() one connection
2: repeat 1 until the accept() system call returns an error
3: handle all requests and return to 0
If the flag is turned off, step 2) above is omitted. The rationale behind
AcceptMulti is that new connections often occur in bursts (especialle on a
page that has a lot of images).
If the file descriptor limit is 164, then setting NumConnections to 1024
does not really make sense, since the server process will only be able to
handle about 82 connections (each connection requires two file
descriptors.) You can turn NumConnections down but that does not really
help of course.
I believe the 164 is a per-process limit. So what you could do is run
`parallel' server processes. Of course each server would have to listen on
a different port. You then run a server on the original port that
redirects to one of the `slave' ports.
E.g. if your server is originally running on port 8080, say, you can set
up five servers that run on ports 8081-8085 and replace the configuration
on the main server with something like this
Server {
Port 8080
Virtual {
AnyHost
Control {
Alias /
Location http://*:8081/
Location http://*:8082/
Location http://*:8083/
Location http://*:8084/
Location http://*:8085/
}
}
}
I admit, this is very ugly, but as far as I can see this is the only way
to work around the low fd limit. (As a historical note, a setup much like
the above was used `in real life' way back in 1996 to work around a 256
fd-per-process limit.)
Hope this helps.
Cheers
Michiel
