On Sun, 2004-08-22 at 08:50 -0400, John Peacock wrote:
> Matt Sergeant wrote:
> > 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...
How does speedycgi compare to pperl? Is pperl being used more as a
generic term for persistent perl processes? Speedycgi has worked
wonderfully for me (Debian Sarge 2.22-1) without any apparent problems.
However, most of the discussions I've seen tend to mention pperl rather
than speedycgi.
If they are not interchangeable, what advantages are there of one over
the other? They seem to both have the same concept (backend pre-
compiled process). Any other users of speedycgi wish to speak up? My
server has a relatively low flow of traffic, so it's not the best
example.
Elliot F.
