[Dovecot] o/s tuning for imap

[Kyle Wheeler]

On Thursday, September  6 at 02:59 PM, quoth Ken A:
>> We found that on our server, *not* using imapproxy improved our 
>> performance. We used to use imapproxy to great effect when we were 
>> using BincIMAP, but Dovecot is so darn fast (and caches its own 
>> authentication) that all imapproxy added was additional 
>> inter-process communication (translation: slower than just using 
>> Dovecot alone).
>
> My understanding is that webmail clients like squirrelmail open, 
> then close connections on each http transaction that requires a 
> connection to the imap server, so imapproxy's caching of connections 
> saves you having to re-open connections to the backend server. 

Yes it does, you are exactly correct. HOWEVER, here's something to 
keep in mind: is that really a problem? Consider, for example, that 
you're not saving any "making a new connection" overhead, because your 
webmail client is still making a new connection to the imapproxy. So, 
connection setup and teardown is still there. If your backend is on 
another machine and your proxy is on localhost, what you're really 
doing is moving the setup and teardown from being done over the 
network to being done over the loopback interface. If your network is 
particularly busy, this *can* be a win, but it may not provide much 
benefit if the connection from webmail server to imap server is a fast 
ethernet connection with not much else to do.

The other thing that an imapproxy changes is it means that the webmail  
client doesn't have to re-authenticate every time; it caches the 
string that the webmail client sent before, and if there's a 
connection open that was approved with those authentication strings, 
you get it. Thus something that might require some hashing and 
possibly an ldap-lookup gets turned into a simple strcmp(). BUT 
dovecot does this already, with its authentication server. So 
imapproxy isn't providing much of a win there either (with dovecot).

You have to consider what the proxy is actually saving you, and 
whether it's worth it. The backend server isn't typically connection 
starved (and if it is, then you haven't configured it properly).

> That's essentially why my original question included "what about 
> time_wait", since I was concerned that squirrelmail could leave a 
> LOT of connections in a TIME_WAIT state.

That's a fair observation, but it's not going to leave any fewer 
connections in such a state if it's connecting to the proxy server 
rather than dovecot.

Personally, on my squirrelmail installation, most users have about 
five or so connections in TIME_WAIT while they're actively using 
webmail. Thus far that hasn't been a problem, but I don't have a 
heavily loaded webmail service.

~Kyle
-- 
University politics are vicious precisely because the stakes are so 
small.
                                                     -- Henry Kissinger
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://dovecot.org/pipermail/dovecot/attachments/20070907/6702e67a/attachment.bin