Brian Grossman wrote:
> > > Try using it as a fastcgi program. Nearly the same speed benefit (skip
> > > exec, skip DB connect), but more flexible, and less likely to crash apache.
> >
> > That was the other option I was considering - either fastcgi, or one of the
>
> Sqwebmail currently has fastcgi support. I use it now on a relatively
> large server.
>
> Fastcgi gives me the following advantages:
>
> Separation of the web server from the cgi server. I'm going to do
> this soon: web server on one side of a firewall; sqwebmail on the
> other side.
>
> Limits server load. I can specify how many connections to serve at
> once. This is good for resource planning and limiting the effect
> of an attack (the load doesn't go to mars).
>
> Persistent db connections. Sam's authdaemon makes this mostly
> irrelevant. (There's still the overhead of connecting to
> authdaemon. Authdaemon only does one auth at a time, I think.)
You are right - fastCGI is supported. I must have been half asleep when I looked
before. That fact you are using it suggests the support is reasonably stable. Do
you see a significant performance boost? Sam suggested there wasn't a lot to gain,
because authdaemon had eliminated the key bottleneck. Seems to me if you remove
the key bottleneck, something else should become the bottleneck, and dragging a
process into life sounds like a good candidate.
Steve
