On Tue, 14 Sep 2010 15:36:04 -0400, Nico Schlömer nico.schloemer@gmail.com wrote:
- How would I find out what the connection speed between the RC and
the IMAP server is?
Capture the traffic with a capture tool like the OSS tool Wireshark (a.k.a. formerly Ethereal).
Then you can see how the pieces are talking to each other, with timing information.
The connection speed (bits per second) doesn't matter as much as the latency, both of the network and the IMAP server. (How heavily loaded is it?)
You know, maybe that IMAP server even has a defense mechanism against too frequent connection attempts! I.e. a chunk of that 5 second delay could simply be a "tarpit" mechanism in the server to protect its resources against badly written clients and denial-of-service attacks.
- Caching doesn't seem to make a big difference. How to find out what
the bottleneck is?
- Any explanation on imapproxy? Never heard of it.
From the imapproxy.org page:
"ImapProxy simply sits between your Webmail server and your IMAP server. It accepts connections from your Webmail server for each client login, then proxies that connection to your real IMAP server. When your Webmail client disconnects, ImapProxy will leave the connection open to the IMAP server such that when your Webmail client reconnects, the existing connection may be re-used."
I.e. imapproxy does what an optimized IMAP client does by itself!
As an alternative to this proxying for connection persistence, you can do replication:
Use fetchmail to periodically pull mail from the remote IMAP server to a local mailbox, and run IMAP locally to serve up this replicated mailbox.
This will be even faster since you are completely eliminating all IMAP transactions between your webmail and the remote IMAP server. You're browsing a purely local store.
But the "send/receive" button on your webmail will not actually be polling the real IMAP server; you're relying on the fetchmail polling (unless you hack that button to kick fetchmail).
List info: http://lists.roundcube.net/users/ BT/9b404e9e