Marcin Michal Jessa wrote:

Russell E. Meek wrote:

...

Quoting Ken A ka@pacific.net:

...

I'm switching from a pop3 only dovecot install to a pop3/imap install and I'm wondering how many connections every 100 'normal' imap users might have/keep open? I'm wondering if I need to tweak any o/s related things, like time_wait, etc. Any pointers would be greatly appreciated.

Thanks, Ken A. OS related tweaks, probably not. However you could utilize a imap proxy such as up-imapproxy which if using FreeBSD is in ports. A propos proxy. Is it possible to run dovecot as an IMAP proxy with load balancing the same way it is possible with Courier and Cyrus? If not, is it on the TODO list?

http://wiki.dovecot.org/HowTo/ImapProxy

Works quite well here.

Ed W wrote:

...

http://wiki.dovecot.org/HowTo/ImapProxy

Works quite well here.

This is very interesting

Does it work ok if you want to have one machine handle the nearly all the normal IMAP traffic, but it has the ability to proxy a few users to a different server?

ie do you need to set it up as a proxy in front of another server, or can you have a hybrid server?

We have dedicated proxies, but I doesn't look difficult to proxy some connections and not others. Just add the appropriate fields, it would seem, though I've never tried it.

In conjuction with some kind of imap folder sync this would be quite cool in a multi-office setup where you can then easily move users mailbox to the closest server where they are working and a few DNS tricks would allow them to turn up in any office and immediately start working.

We use mysql for the backend so it simply requires an UPDATE statement to point a user to a different drbd storage set. We use rsync to move domains from set to set when necessary.

Kyle Wheeler wrote:

On Tuesday, September 4 at 08:26 PM, quoth Russell E. Meek:

...

OS related tweaks, probably not. However you could utilize a imap proxy such as up-imapproxy which if using FreeBSD is in ports.

Visit: http://www.imapproxy.org/ to learn more.

This should relieve the load on Dovecot.

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).

~Kyle

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. 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.

Thanks for your other suggestions, Ken

-- Ken Anderson Pacific.Net

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