Re: siege failing and so on

-                                                 [email protected]
---------------------------------------------------------------------

Problems trying to solve:
- to many processes/threads
- socket-security
- keep-alive
- https (ssl) handling
- good seperation of vhost-processes

If it were up to me it'd create one process which works with a
non-blocking select which handles all incoming requests, parses the
headers, selecting a child (maybe telling the master-process to start one,
if it hasn't yet, that would be nice), passing the request along over a
Unix domain-socket and then keeping an eye on where the body ends.

ssl can be handled two ways, when something connects to a ssl-port, you
know which address to the outside world it is, so just pass it along to
the right vhost. Or you can unencrypt it in the select loop (with a
seperate thread maybe ?) and the pass it along unencrypted.

pros:
- solves all above problems, as far as I can see it.

(it should have good performance too, it's a lot like serving static
content and it has been shown this is one way of doing it very fast)

con:
- how to handle IP-addresses for the logs

I guess it can be fairly easily solved by adding it to the headers (just
like you'd do with a reverse-proxy or passing along a request to a servlet
engine ?).

Maybe there was a good reason not to use this model, I forgot if it's true
(then I apologize), but it still seemed like a good idea to me. And I just
hope I was being sensible and it was usefull to the discussion.

PS If your worried of performance degration with a lot of connections,
then Linux has an extension which gives you an array which tells you what
connections have data (instead of needing to check them all).

_____________________________________
New things are always on the horizon.