[Dovecot] Proxying Performance vs imapproxy
Hi,
I'm planning on a new mail infrastructure which constists of multiple 'frontends' running webmail & public access pop/imap, which would communicate over imap/pop to 'backend mail stores'. My original idea was to run dovecot on the backends, use a predition on the frontends to proxy imap/pop and also run imapproxy in front of webmail [squirrelmail].
I've since read about the dovecot proxying features and it seems to make sense to replace predition in that above scenario.
I'm unclear about the benefits of the auth_cache and how it compares to the using imapproxy in front of webmail client?
Does it make sense to have authcaching switched on in the proxy and not on the backend server? (Doesn't the authentication just have to happen on the backend server?)
Are there any performance benefits to using a proxying server, or is it just for splitting mailstores?
thanks for your work,
Dan Poltawski
You didn't get much answer to this - I'm probably not the best person to answer, but
Are there any performance benefits to using a proxying server, or is it just for splitting mailstores?
I think this is the main reason for the proxying option. It would appear that others have measured the performance load of the proxy task and found it near negligible? Hence it seems possible to use a bunch of backend servers and a few frontend servers to forward the user to the correct backend server. I believe each connection needs to be setup each time though, so for sure some more advanced proxies with persistent caching of connections may offer a performance improvement if your servers are loaded due to the login part (but I guess measure this first before assuming it's so?)
Some have even used the backend servers as the frontend proxy servers, ie if you only have a small number of servers then make them all frontend and backend servers, eg with three servers you have a 1 in 3 chance of getting straight onto the correct server, otherwise proxy over to the correct server...
Good luck
Ed W
On Seg, 2009-09-28 at 15:55 +0100, Ed W wrote:
You didn't get much answer to this - I'm probably not the best person to answer, but
Are there any performance benefits to using a proxying server, or is it just for splitting mailstores?
I think this is the main reason for the proxying option. It would appear that others have measured the performance load of the proxy task and found it near negligible? Hence it seems possible to use a bunch of backend servers and a few frontend servers to forward the user to the correct backend server. I believe each connection needs to be setup each time though, so for sure some more advanced proxies with persistent caching of connections may offer a performance improvement if your servers are loaded due to the login part (but I guess measure this first before assuming it's so?)
Proxy servers are usually set between the webmail and the imap server.
That's because webmails are a bitch regarding opening+closing connections and so the proxy gets most of connection + auth + do something + disconnect and keeps a limited pool of per user connections to the imap servers that it re-uses. Proxies are usually installed on the same servers that the webmail, with the webmail connecting to 127.0.0.1:someport.
-- Jose Celestino SAPO.pt::Systems http://www.sapo.pt --------------------------------------------------------------------- * Progress (n.): The process through which Usenet has evolved from smart people in front of dumb terminals to dumb people in front of smart terminals.
Jose Celestino wrote:
On Seg, 2009-09-28 at 15:55 +0100, Ed W wrote:
You didn't get much answer to this - I'm probably not the best person to answer, but
Are there any performance benefits to using a proxying server, or is it just for splitting mailstores?
I think this is the main reason for the proxying option. It would appear that others have measured the performance load of the proxy task and found it near negligible? Hence it seems possible to use a bunch of backend servers and a few frontend servers to forward the user to the correct backend server. I believe each connection needs to be setup each time though, so for sure some more advanced proxies with persistent caching of connections may offer a performance improvement if your servers are loaded due to the login part (but I guess measure this first before assuming it's so?)
Proxy servers are usually set between the webmail and the imap server.
That's because webmails are a bitch regarding opening+closing connections and so the proxy gets most of connection + auth + do something + disconnect and keeps a limited pool of per user connections to the imap servers that it re-uses. Proxies are usually installed on the same servers that the webmail, with the webmail connecting to 127.0.0.1:someport.
That's what he was asking about, however, I don't think that dovecot's proxy does in fact do this for you? I believe
However, it's probably worth checking if it's an issue in your installation before over tuning - I think that dovecot's login caching can make this a fairly inexpensive process.
Caveat: I don't have anything like this kind of setup and am not offering an informed opinion...
Good luck
Ed W
On Mon, 2009-09-28 at 19:02 +0100, Ed W wrote:
Proxy servers are usually set between the webmail and the imap server.
That's because webmails are a bitch regarding opening+closing connections and so the proxy gets most of connection + auth + do something + disconnect and keeps a limited pool of per user connections to the imap servers that it re-uses. Proxies are usually installed on the same servers that the webmail, with the webmail connecting to 127.0.0.1:someport.
That's what he was asking about, however, I don't think that dovecot's proxy does in fact do this for you? I believe
Right, Dovecot doesn't do connection caching.
However, it's probably worth checking if it's an issue in your installation before over tuning - I think that dovecot's login caching can make this a fairly inexpensive process.
Yeah. imapproxy probably reduces the load a bit, but it probably isn't anything dramatic with Dovecot. My guess is that it would only reduce CPU load, but if it's at ~1% already then there's not that much point..
On Mon, 2009-09-28 at 14:06 -0400, Timo Sirainen wrote:
Yeah. imapproxy probably reduces the load a bit, but it probably isn't anything dramatic with Dovecot. My guess is that it would only reduce CPU load, but if it's at ~1% already then there's not that much point..
BTW. I'm only talking about systems where mailboxes are on local disk. With NFS each login would trigger some NFS reads which could slow things down more. With local mails those things would already most likely be cached in memory.
On Seg, 2009-09-28 at 14:06 -0400, Timo Sirainen wrote:
On Mon, 2009-09-28 at 19:02 +0100, Ed W wrote:
Proxy servers are usually set between the webmail and the imap server.
That's because webmails are a bitch regarding opening+closing connections and so the proxy gets most of connection + auth + do something + disconnect and keeps a limited pool of per user connections to the imap servers that it re-uses. Proxies are usually installed on the same servers that the webmail, with the webmail connecting to 127.0.0.1:someport.
That's what he was asking about, however, I don't think that dovecot's proxy does in fact do this for you? I believe
Right, Dovecot doesn't do connection caching.
However, it's probably worth checking if it's an issue in your installation before over tuning - I think that dovecot's login caching can make this a fairly inexpensive process.
Yeah. imapproxy probably reduces the load a bit, but it probably isn't anything dramatic with Dovecot. My guess is that it would only reduce CPU load, but if it's at ~1% already then there's not that much point..
No, you're right, it was much much worse with courier-imap :) We haven't really measured it since it was so obvious with courier. But we do spare some time with fs stats and checkpassword work, and we get a ready connection with a hot cache.
-- Jose Celestino SAPO.pt::Systems http://www.sapo.pt --------------------------------------------------------------------- * Progress (n.): The process through which Usenet has evolved from smart people in front of dumb terminals to dumb people in front of smart terminals.
participants (4)
-
Dan Poltawski
-
Ed W
-
Jose Celestino
-
Timo Sirainen