Oh erm, that's with Firefox 3.6.9 and Opera 10.61 on a Linux platform.

Well, I didn't really consider that this might have to do with the browser really, as the pages all load fine. It's just that I have to stare at the "Loading..." animation for so long.

Cheers, Nico

On Tue, Sep 14, 2010 at 2:31 PM, Arne Berglund aberglund@lesd.k12.or.us wrote:

On Tue, 14 Sep 2010 14:25:00 -0400, Nico Schlömer nico.schloemer@gmail.com wrote:

...

Dear all,

I'm running a RoundCube installation on a FreeBSD server here, and it's fed by a *remote IMAP server. As recommended in the settings, I set

$rcmail_config['enable_caching'] = true;

but despite this, accessing the mails is *dead slow. It takes at least 5 seconds to access any given folder, and this doesn't seem to change after the folder has been accessed once (and hence cached?). This makes using RoundCube quite inconvenient. I'm quite oblivious as to what could cause such a slow performance, but I'm willing to test and try. Hints, anyone?

What browsers? We've found that IE older than IE8 is so slow as to be pretty much useless.

-- Arne Berglund System Administrator, Internet Services Lane Education Service District Eugene, OR ____________

List info: http://lists.roundcube.net/users/ BT/9b404e9e

Nico Schlömer put forth on 9/14/2010 1:25 PM:

Dear all,

I'm running a RoundCube installation on a FreeBSD server here, and it's fed by a *remote IMAP server. As recommended in the settings, I set

$rcmail_config['enable_caching'] = true;

but despite this, accessing the mails is *dead slow. It takes at least 5 seconds to access any given folder, and this doesn't seem to change after the folder has been accessed once (and hence cached?). This makes using RoundCube quite inconvenient. I'm quite oblivious as to what could cause such a slow performance, but I'm willing to test and try. Hints, anyone?

1. What is the link speed of the slowest network connection between the

RC server and the IMAP server? What is the round trip packet time between the two, i.e. ping, and how many hops, i.e. traceroute?

2. Do you have imapproxy installed on the RC server?

3. What web server are you using?

4. What version of PHP?

5. What version of FreeBSD?

6. What are the hardware specs (CPU speed/mem size) of both the RC

server and the IMAP server?

7. What IMAP server daemon/version is running on the IMAP server?

On Tue, 14 Sep 2010 11:42:08 -0700, Arne Berglund aberglund@lesd.k12.or.us wrote:

Well, something doesn't seem right, then. I've got 0.4-stable in production now (apache on linux) connecting to a separate IMAP server (dovecot on linux as well). Granted, both boxes are in the same rack and on 1000BaseT ports on the same switch,

The difference between being on the same switch (gigabit, at that) and using the 127.0.0.1 loopback interface is negligible. This setup does not really satisfy some of the key meanings of "remote".

In addition to error logs, I would whip out Wireshark or tcpdump and look at the network-level interaction between the mail client and IMAP server.

List info: http://lists.roundcube.net/users/ BT/9b404e9e

Arne Berglund put forth on 9/14/2010 1:42 PM:

Well, something doesn't seem right, then. I've got 0.4-stable in production now (apache on linux) connecting to a separate IMAP server (dovecot on linux as well). Granted, both boxes are in the same rack and on 1000BaseT ports on the same switch, but it's still having to go box-to-box for everything. I don't even have caching enabled, and things seem to work reasonably fast.

Caching isn't required for good performance when you have a 100 MB/s pipe with sub 1 ms latency between the RC and IMAP servers. If the average broadband connection is DSL/cable at 2 Mb/s that's a 500x difference in B/W.

If you were to locate your RC server across town on a DSL/cable line your RC performance would drop considerably due to that 500x decrease in bandwidth and latency increase of over 30x. In this scenario, RC caching and imapproxy would help quite a bit.

Nico Schlömer put forth on 9/14/2010 1:51 PM:

The IMAP server in the present setup is installed in some physical distance to the RoundCube server I believe, it's running some Microsoft thing and generally I would say is not well administered. This could potentially be the culprit (but wouldn't explain why it's still slow with caching enabled). Is there any way I could test or benchmark this?

With no details of the server available, the only other thing you can do on the RC box to possibly increase performance is install imapproxy, which will eliminate the constant log on/off cycles of this stateless web app.

You do realize that every mouse click on an item or folder in RC (or almost every click) sends an IMAP login to the server, and a logout after the command has completed, don't you?

logon -> command -> logoff for just about every mouse click in RC

This constant authentication and IMAP process creation/tear down put one helluva load on an IMAP server, assuming it's not a hobby server, and likely especially, any MS server running a Win32 IMAP server. If the IMAP server is the Exchange component, doubly so.

Given the fact your RC server is remote, I'm kinda shocked you don't have imapproxy installed already.

http://imapproxy.org/

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

Hi Stan,

I'm sorry that my not clarifying the background of this unsettled you somewhat.

I'm a PhD student at the University of Antwerp http://win.ua.ac.be/content/staff and like many of my colleagues, I was dissatisfied with the webmail interface that the ICT would provide: It's old, it's buggy, and it seems unmaintained. Frustrating, but oh well, I guess that's how it goes sometimes. Anyway, some friends and I decided to have a look into free webmail solutions for us to use at the Computer Science department, and to play around with them a bit to see what's actually possible. This is purely a spare-time activity really, but the success in setting up RoundCube and getting a nice and modern webmail interface was quite satisfactory.

Of course I don't demand official support for this in any way, but because of our performance problems I thought I'd just drop a line to the users' mailing list. Sorry if you felt startled by this. It's cool if you decide to ignore these mails of course, I mean, that's what people do with 99% of their mailing lists I guess. Anyway, thanks for your help so far.

You are posting here with a gmail address instead of your university address.

This is b/c the UA email doesn't perform well in some areas -- incredibly long delivery delays, 500MB mailbox limit, other funny things.

Cheers, Nico

On Tue, Sep 14, 2010 at 4:58 PM, Stan Hoeppner stan@hardwarefreak.com wrote:

Nico, do you have permission/authorization to connect this RC server to the campus Exchange server?  You are posting here with a gmail address instead of your university address.  This leads me to believe you are not acting in an official capacity.

Furthermore, if you are not a member of the university IT staff, it is possible that network layer (router/qos) roadblocks are the reason for the abysmal performance, and you will never know this.  If _we_ are to help you make this RC server function properly, we require accurate answers to our questions.  If you cannot provide that accurate information, we won't be able to fully help you.

Keep in mind none of us wants to assist a rogue student in doing something against university policy or without proper permission. Hacking is a personal endeavor, not one that should involve IT professionals around the world who are spending their valuable time assisting you in something that may very well be illegal in your jurisdiction.

Are you authorized to be doing this?  If so, get the information on the Exchange server, and interface with its admin staff to optimize your RC performance.

-- Stan

Nico Schlömer put forth on 9/14/2010 2:05 PM:

...

PING imap.ua.ac.be (143.169.245.58): 56 data bytes 64 bytes from 143.169.245.58: icmp_seq=1 ttl=124 time=2.053 ms

...

traceroute to imap.ua.ac.be (143.169.245.58), 64 hops max, 52 byte packets  1  pcfw1 (143.129.75.14)  0.655 ms  0.695 ms  0.472 ms  4  143.169.251.100 (143.169.251.100)  1.725 ms  1.471 ms  1.217 ms

Both machines are on the same friggin campus network Nico.  I'm very glad now I asked these questions.  I'm probably not the only one who thought this RC server was fairly remote to the IMAP server...

...

...

2. Do you have imapproxy installed on the RC server?

Never heard of that.

See my other post.

...

...

3. What web server are you using?
4. What version of PHP?
5. What version of FreeBSD?

http://win.ua.ac.be/~nschloe/other/phpinfo.php

All good.

...

...

6. What are the hardware specs (CPU speed/mem size) of both the RC

server and the IMAP server?

RC server:

• 4 cores,

CPU: Intel(R) Xeon(R) CPU           E5405  @ 2.00GHz (1999.78-MHz K8-class CPU)

• 8 GB mem

No apparent problems here.

...

I'd like to benchmark PHP applications in general, or have some sort of general web application benchmark anyway. Suggestions?

None from me.  Your PHP implementation isn't the problem here.

...

I have no idea about the hardware specs of the IMAP server.

Too bad the Exchange server IMAP string below doesn't tell us. ;)

...

...

7. What IMAP server daemon/version is running on the IMAP server?

It must be one of those Microsoft Server installations -- no idea what version though. Remote benchmark possible?

Now that I have the server IP, I can answer my own question.  Look at the very last line below.  It's the Exchange 2003 IMAP connector.  So you were indeed correct about the IMAP server being Microsoft.  FWIW, the connection establishment time from Missouri, USA is instantaneous, even though the latency is in the 150-200ms range.

[03:27:35][stan@greer]~$ openssl s_client -connect 143.169.245.58:993

CONNECTED(00000003) depth=1 /C=BE/O=Cybertrust/OU=Educational CA/CN=Cybertrust Educational CA <snip><snip><snip>  0 s:/C=BE/ST=Antwerp/L=Antwerp/O=Universiteit Antwerpen/OU=ICT/CN=webmail.ua.ac.be

<snip><snip><snip>

• OK Microsoft Exchange Server 2003 IMAP4rev1 server version 6.5.7638.1

(xmailf3.ad.ua.ac.be) ready.

---

List info: http://lists.roundcube.net/users/ BT/500a1e2e

List info: http://lists.roundcube.net/users/ BT/9b404e9e

On Tue, 14 Sep 2010 17:21:42 -0400, Nico Schlömer nico.schloemer@gmail.com wrote:

Hi Stan,

I'm sorry that my not clarifying the background of this unsettled you somewhat.

I'm a PhD student at the University of Antwerp http://win.ua.ac.be/content/staff and like many of my colleagues, I was dissatisfied with the webmail interface that the ICT would provide: It's old, it's buggy, and it seems unmaintained.

One solution would be to set up a mail server in the CS department; maybe the University IT would go for that, depending on the rapport between them and the CS dept.

Give this mailo server its own mail domain (MX record).

Then install whatever mail handling software you want for you and your colleagues.

The only missing piece would be to forward your University e-mail (going to you@university) to your CS mail server (you@cs.university).

This could be achieved if the university mail system provides forwarding.

From your cs mail, you could still use the you@university address for sending; no need to reveal you@cs.university.

List info: http://lists.roundcube.net/users/ BT/9b404e9e

On Tue, 14 Sep 2010 18:51:35 -0500, Stan Hoeppner stan@hardwarefreak.com wrote:

Kaz Kylheku put forth on 9/14/2010 5:35 PM:

...

One solution would be to set up a mail server in the CS department; maybe the University IT would go for that, depending on the rapport between them and the CS dept.

This is technically feasible.

...

Give this mailo server its own mail domain (MX record).

This is probably not politically feasible.

...

Then install whatever mail handling software you want for you and your colleagues.

The only missing piece would be to forward your University e-mail (going to you@university) to your CS mail server (you@cs.university).

This is properly done with mail _routing_ not forwarding. You don't want to use forwarding in this scenario.

In this scenario, there is mail coming in which is directed to "person@university". Whether or not it goes to "person@cs.university" is determined strictly on the identity of "person" and nothing else. Moreover, the address has to be rewritten to "person@cs.university" (the proper mail domain of the target server).

This is functionally indistinguishable from forwarding.

The admins probably don't want to maintain such a mapping themselves, if it can be achieved by a self-serve forwarding configuration.

Correct my misunderstanding, but mail routing would be if the "university" mail server also accepted mail for the "cs.university" domain, and passed it on to the right server, no?

List info: http://lists.roundcube.net/users/ BT/9b404e9e

Kaz Kylheku put forth on 9/14/2010 7:25 PM:

Correct my misunderstanding, but mail routing would be if the "university" mail server also accepted mail for the "cs.university" domain, and passed it on to the right server, no?

There is only one domain, university.edu. cs.university.edu is a host on the network, not a sub domain of university.edu. All mail is sent to user@university.edu. What the mailhub does is look at the user tables to determine if a mailbox is local or on another university host. In the latter case, there will be an entry in /etc/aliases for each user address that needs to be delivered to another host. Here's a link detailing how to do this in Postfix:

http://www.postfix.org/STANDARD_CONFIGURATION_README.html#local_network

Wietse uses the word "forward" in his how-to which I don't agree with. In a purely technical mail delivery sense, the two words "routing" and "forwarding" are interchangeable. But in the practical sense, the internet layperson has a distinct notion of what "forwarding" an email is, and the same layperson will have never heard the term "mail routing". This is why I use these words distinctly and definitively.

Forwarding is: user@gmail.com to other-user@yahoo.com

Routing is: bob.smith@university.edu to bob.smith@cs.university.edu

In the case of forwarding, mail is being sent from one account at one domain to another account at another domain.

In the case of routing, mail is being received for a user at a domain mailhub host and routed to another host in the domain where his mailbox is stored. When this user sends mail to user@gmail.com, it is submitted to cs.university.edu which then relays it to the mailhub host, which then relays it to the destination domain. When this user sends an email to jane.doe@university.edu, who is not in the CS department, the MTA on cs.university.edu looks up the alias for jane.doe which points to history.university.edu and routes the email to her mailbox on the history dept server. These examples are not "forwarding" of email, but "routing" of email.

Enable imap_debug and check the log, it will show you which command is slow if it's IMAP problem.

Aha! This tells me more about what's slow indeed: When clicking on a folder, all the messages are fetched one after the other, the logs spitting out something along the lines of

========================================= *snip*

[...]

[15-Sep-2010 18:21:47 +0200]: S: ) [15-Sep-2010 18:21:47 +0200]: S: * 621 FETCH (INTERNALDATE " 9-Sep-2010 14:19:43 +0200" BODY[HEADER.FIELDS (DATE)] {47} [15-Sep-2010 18:21:47 +0200]: S: Date: Thu, 9 Sep 2010 14:18:59 +0200 (CEST)

[...] ========================================= *snap* =========================================

Each one of those calls takes some time (about 0.07 secs), and for folders with more than 1500 messages in it that's sums up to about 2 minutes. This is were the delay sits. I'm not sure about the implications. Would that mean that the connection to the server is slow?

Cheers, Nico

On Wed, Sep 15, 2010 at 2:24 AM, A.L.E.C alec@alec.pl wrote:

On 14.09.2010 20:25, Nico Schlömer wrote:

...

I'm running a RoundCube installation on a FreeBSD server here, and it's fed by a *remote IMAP server. As recommended in the settings, I set

$rcmail_config['enable_caching'] = true;

but despite this, accessing the mails is *dead slow. It takes at least 5 seconds to access any given folder, and this doesn't seem to change after the folder has been accessed once (and hence cached?). This makes using RoundCube quite inconvenient.

Enable imap_debug and check the log, it will show you which command is slow if it's IMAP problem. If the login process is slow, then imapproxy could help.

Other tips: http://trac.roundcube.net/wiki/Howto_Performance

ps. I don't use caching in Roundcube, but I know it's code. Caching has some issues and is slow in some cases. Caching is also not used when threading is enabled. One issue is that you need to have all messages in cache to use it. It means, if you have a few pages on the list, you'll need to display them all, to make sure that Roundcube stores all messages in the cache.

-- Aleksander 'A.L.E.C' Machniak http://alec.pl gg:2275252 LAN Management System Developer http://lms.org.pl Roundcube Webmail Developer http://roundcube.net _______________________________________________ List info: http://lists.roundcube.net/users/ BT/500a1e2e

List info: http://lists.roundcube.net/users/ BT/9b404e9e

It looks that your IMAP server doesn't support SORT command,

Indeed:

===================================== *snip*

[...] 15-Sep-2010 19:22:05 +0200]: S: * OK Microsoft Exchange Server 2003 IMAP4rev1 server version 6.5.7638.1 (xmailf3.ad.ua.ac.be) ready. [15-Sep-2010 19:22:05 +0200]: C: cp01 CAPABILITY [15-Sep-2010 19:22:05 +0200]: S: * CAPABILITY IMAP4 IMAP4rev1 IDLE LOGIN-REFERRALS MAILBOX-REFERRALS NAMESPACE LITERAL+ UIDPLUS CHILDREN [...] ===================================== *snap* =====================================

Go to message list options menu and select "None" in "Sorting column" fieldset.

That *did help a great deal. I adapted the default sorting in the main.conf and things are a lot faster now. Thanks!

Now it's the actual message headers

===================================== *snap*

[...] [15-Sep-2010 19:24:37 +0200]: S: ) [15-Sep-2010 19:24:37 +0200]: S: * 40 FETCH (UID 40 RFC822.SIZE 80687 FLAGS (\Seen) INTERNALDATE "28-Jul-2009 22:00:33 +0200" BODY[HEADER.FIELDS (DATE FROM TO SUBJECT REPLY-TO IN-REPLY-TO CC BCC CONTENT-TRANSFER-ENCODING CONTENT-TYPE MESSAGE-ID REFERENCES DISPOSITION-NOTIFICATION-TO X-PRIORITY X-DRAFT-INFO)] {297} [15-Sep-2010 19:24:37 +0200]: S: Date: Mon, 21 Jan 2008 18:18:18 +0200 From: "Tammy Kolda" nadigest@comcast.net To: na-digest@cs.utk.edu Subject: NA Digest, V. 08, # 03 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C85C4A.0DDD4780" Message-ID: 200801211618.m0LGIIfw025483@netlib2.cs.utk.edu [...] ===================================== *snap* =====================================

which cause most of the loading time.

--Nico

On Wed, Sep 15, 2010 at 1:12 PM, A.L.E.C alec@alec.pl wrote:

Nico Schlömer wrote:

...

Aha! This tells me more about what's slow indeed: When clicking on a folder, all the messages are fetched one after the other, the logs spitting out something along the lines of

========================================= *snip*

[...]

[15-Sep-2010 18:21:47 +0200]: S: ) [15-Sep-2010 18:21:47 +0200]: S: * 621 FETCH (INTERNALDATE " 9-Sep-2010 14:19:43 +0200" BODY[HEADER.FIELDS (DATE)] {47} [15-Sep-2010 18:21:47 +0200]: S: Date: Thu, 9 Sep 2010 14:18:59 +0200 (CEST)

[...] ========================================= *snap* =========================================

Each one of those calls takes some time (about 0.07 secs), and for folders with more than 1500 messages in it that's sums up to about 2 minutes. This is were the delay sits. I'm not sure about the implications. Would that mean that the connection to the server is slow?

It looks that your IMAP server doesn't support SORT command, so only solution is to use default sorting. Go to message list options menu and select "None" in "Sorting column" fieldset.

-- Aleksander 'A.L.E.C' Machniak http://alec.pl gg:2275252 LAN Management System Developer http://lms.org.pl Roundcube Webmail Developer http://roundcube.net _______________________________________________ List info: http://lists.roundcube.net/users/ BT/500a1e2e

List info: http://lists.roundcube.net/users/ BT/9b404e9e