Alexei Batyr' writes:
Sam, Would you consider conversion of sqwebmaild into full-fledged FCGI server? We (as rapidly growing number of web site owners) are using light and fast HTTP server nginx instead of apache. Nginx does not support CGI, only FCGI, so on the mail server I have to run both nginx and apache - latter exclusively to support Sqwebmail. It would be nice if sqwebmaild could work as FCGI server, probably as well as CGI or only as FCGI - apache and other popular HTTP servers supports it, so for apache users it would be just small change in configuration.
sqwebmail's code, unfortunately, isn't really clean enough to meet the requirements of a FCGI-based server. Furthermore, I am doubtful whether or enough there will be any noticable difference, anyway. sqwebmaild is already a memory-resident daemon, by default, and sqwebmail is merely a stub that proxies each request to sqwebmaild. With sqwebmaild's prefork-based process model, I'm doubtful whether or not FCGI could improve on sqwebmaild. All that FCGI does is what sqwebmaild is already doing, anyway, with the only possible cost savings being a fork() system call, which, on Linux and UNIX, is very lightweight.
It's possible that there might be a few drops of juice squeezed by making the sqwebmail stub a FCGI-based server, but I'm still somewhat skeptical. The sqwebmail binary is tiny. It almost does not exist. Unless a server is completely out of resources, the sqwebmail executable image would probably stay cached in RAM anyway.
I believe that the primary limiting factor is really bandwidth, not CPU.
pgptPbxuyCU2y.pgp
Description: PGP signature
------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev
_______________________________________________ courier-users mailing list [email protected] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
