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