It goes like this:
with more detail...
- tcpserver - stablest, slowest.
Each SMTP session spawns a new instance of qpsmtpd (meaning Perl has to start up _every_ time).
- forkserver - stable, fast.
Each SMTP session is handled by a forked copy of qpsmtpd (meaning that Perl is already resident and fork just [re]uses the same mmapped code).
- pperl - concerns over stability, fastest.
Each SMTP session is handled by a prespawned instance of qpsmtpd (trading off memory for speed). This is the way that Apache has historically operated (i.e. in Apache 2.0 the prefork MPM, not the worker MPM).
AFAIK, pperl is faster than forkserver because even fork takes some time to copy the non-shared data; I wonder if the COW (copy on write) patch to Perl would make that still true (or is that strictly just ithreads, not fork)...
One thing I find less optimal about both forkserver and pperl is that if I change a plugin, I have to restart the entire thing to get it to take (even in a production environment, sometimes tweaks happen ;). I wonder if it would be worth while to add a handler so $SIG{HUP} would trigger a fresh $plugin_loader->load_plugins() as well as a reread of config/plugins, too...
HTH
John
