Roundcube performance

[Enrico Tagliavini]

Hello everyone,

I was wondering if anybody has some suggestion on how to make roundcube in
kolab 3.2 (and 3.3 as well since I plan to upgrade before Christmas I hope)
a little bit faster.

Prologue: in kolab 3.0 and 3.1 roundcube was not very fast.... but still
acceptable. Updated to kolab 3.2 and, while roundcube interface is better,
prettier than before it is also slower (no idea if updat of cyrus imap can
be blamed as well but I don't think so). Slower to the point of being
annoying.

My config: this is a 3 users system, nothing big. spool/imap is about 118
MB with about 12000 files. I first installed this with kolab 3.0 a couple
of years ago and updated it as new releases where coming out. The system
runs on a VM, with 2 vcores and 3 GB of ram. The host is under my direct
control and fr the reference it is a SYS from OVH. Host processor is a Xeon
E3-1225 with 32 GB of ram, with an average use of cpu time under 5%
according to munin. The 2 hard drives are in software raid one on the host,
and the disk image for the kolab VM is an LVM logical volume passed
directly to the VM. The hypervisor is KVM, OS is CentOS 6.5 both on host
and guest. The file system for the imap folders is the same has /, with
stock ext4 options. For such a small spool I don't think separating it
would make much difference, but feel free to correct me and suggest better
settings.

To quantify slow in roundcube I would say that opening an uncached message
takes an average time of 2-4 seconds (according to firefox network console
/ firebug), refresh can take even more sometimes. Switching folder is the
same. In some rare cases some operation can reach 10 seconds, but this is
quite rare. This is not network latency since it happens also from work
networks. From work I have access to two networks, one is a 100 mbit eth,
the second is 1gbit eth. Average latency to my server is about 13ms ± 0.2,
measured with both ping (average in 50 samplings) and mtr.

I have no clue what could be the bottleneck, the only symptom I can see,
other than the slow speed, is a lot of I/O wait in the kolab VM, likely
from imapd. Munin confirms that from kolab 3.1 to kolab 3.2 the cpu I/O
wait time increased quite a bit. I would roughly say it is doubled, from
~2% to 3-4%. But it is hard to say since the values are small. Anyway I can
see the I/O wait clearly with htop while refreshing or opening uncached
messages. I can't be sure if this I/O is from disk or from network. For
both I use virtio. For the disk I switched to virtio SCSI just to see if it
was making any difference.

So far I've tried to add imapproxy between roundcube and cyrus-imap. I had
to do some odd config here since roundcube will refuse to connect to
anything else that localhost:143, ignoring whatever I put into the config
file (I tried to put imapproxy on 144 at the beginning, this bug has been
reported in roundcube in the past already). So I moved cyrus-imap and bound
it to the external IP only and got imapproxy on 127.0.0.1 only.

With imapproxy the roundcube performance increase dramatically, but
unfortunately the unread messages display is broken. The unread message
cunt on the left is correct, but I have to force the view to unread
messages only to actually be able to see them. Just opening a folder with
uncached unread messages lists only the cached one (what you already read)
:(. I've tried to disable caching in roudcube, both for messages and imap,
the result seem the same oddly. I'll keep it disabled for a while and see
if the behaviour changes. I saw an old bug report for roundcube describing
this behaviour, but can't find it again right now... sorry.

So my question is what can I do to speed up roundcube a bit without
breaking it.

Also, as a suggestion to Kolab developers: I think investigating the
possibility of adding imap proxy caching to kolab would be very worth it,
if you didn't already. Performance gain is massive. Provided it doesn't
break roundcube itself like in my case of course. I'm not aware of any
other imap proxy other than the squirrel mail one.... tried with nginx but
it want to do fancy stuff for the authentication so I didn't even tried it.

Thank you.
Best regards

Enrico
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kolab.org/pipermail/users/attachments/20140915/4614c3dd/attachment.html>