On Wed, May 11, 2011 at 08:39:49AM -0700, Eric S. Eberhard wrote:
> I have found that fork() on modern machines as a negligible affect on
> performance and in fact I almost always use inetd instead of writing my own
> servers, mainly because it is dead reliable, easier to code, and again
> seems to have negligible affect on performance. One would have to do
> millions upon millions of connects to notice or care. Having said that, I
> use AIX mostly, and that performs better under load than Linux on Intel,
> and even Linux on the IBM p series platform. I would do it cheap and easy
> and worry about performance after-the-fact. Eric
Let's not start an OS A is better than OS B discussion here. You can
safely fork single-threaded OpenSSL servers right after accept(3),
and handle the SSL connection in a child. This makes the memory-resident
session cache ineffective, but you can use callbacks to implement an
external (Berkeley DB similar or shared memory, ...) session cache.
Forking after SSL_accept() is tricky, since your parent process will
have partial SSL connections in progress for other clients when a given
handshake completes (event-based connection management) or will serialize
all handshakes, but as you've observed that's not a good option.
So, my suggestion is that a forking server is fine, just use an external
session cache. The Postfix SMTP server is an example of this model. There
before the TLS handshake, we also have an SMTP STARTTLS handshake, but
that does not alter the analysis in any substantive way, just a few more
packets to exchange before the TLS connection is ready.
Note, Postfix is pre-forking, rather than forking, so there is a pool
of processes, that serially accept connections, but this too does not
impact the design analysis.
- You can use a single process with event-based I/O.
- You can use multiple threads in a single process.
- You can fork after accept(2) and use an external session cache
- You can pre-fork and handle clients serially one per process,
with re-use of processes for another client after a client hangs-up.
This too requires an external session cache.
--
Viktor.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
