I have been hearing aout this new sqwebmaild process and was wondering if somebody could give me a little more clarification as to the purpose and benefit of this.
As it is right now, our sqwebmail process is very slow to load on our server, due to the large collection of messages in our folders. Our .Spam folder normally averages about 10K messages (and that is only for the past 7 days, anything older is purged). I assume the delay is from the dir hash as well as the sheer number of messages that have to be moved from ./.Spam/new to ./.Spam/cur when you view the messages. (This is all on FreeBSD 4.8 with a RAID5 NFS backend.)
I was mainly wondering if this new sqwebmaild functionality would enable
a faster more responsive sqwebmail app in general.
Tom Walsh Network Administrator http://www.ala.net/
I very recently attempted to do just that in another thread. Here's my (brief) take on it, in case you missed it. I believe it's mostly accurate. -- Of course it's also mostly air, and little substance. So, I suspect you might need Sam himself to comment if anything further needs to be said on the matter.
On Friday, Jan 2, 2004, at 10:52 US/Central, James A Baker wrote:
My understanding from Sam's remarks is that the CGI was split into these 2 parts to allow for a pre-forked process model, which itself was chosen as a means to obviate the need for having a setuid binary as was previously required in most setups. (That's how I understood it anyway.)
As far as I know, therefore, any speed up (or slow down, of which there hopefully isn't any) due to the split process (CGI and daemon) is likely to be incidental and marginal. I don't believe the change had anything to do with increasing responsiveness, not in large folders nor otherwise. -- My impression from what I've gathered is that it was merely to avoid the need for a setuid binary to be run by a web server. Many people feel insecure doing so on their servers... even with Sam's fine record in regard to security measures.
-jab
