[Dovecot] o/s tuning for imap

[Ken A]

Kyle Wheeler wrote:
> 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


What I've found is that using squirrelmail with imapproxy to dovecot is 
is faster because TLS connections are cached.

Without TLS, squirrelmail is faster without imapproxy. So, if 
squirrelmail and dovecot are on the same box, imapproxy will only slow 
things down.

So, imapproxy saves more than it costs by caching TLS connections, and 
it's a lot cheaper than a couple of accelerator cards.

Ken


-- 
Ken Anderson
Pacific.Net