Roundcube performance

Fri Sep 19 08:51:15 CEST 2014

I enabled the audit log in cyrus and also the iolog. Nothing strange to
report from there. Most operations from roundcube will trigger a write of
small size according to iolog, usually around 50k. Strange it reports no
reads though.

I checked iostat and iowait is 50% (the VM has 2 cores). Looking at ps aux
output there is one, or sometimes two imapd proccesses in "Uninterruptible
sleep" state, likely waiting for flushing the write to disk. I have no idea
what's the expected performance of cyrus imap on bare metal,
virtualization adds an overhead here, but so big looks strange. A non
cached folder listing can take up to 4 seconds and loading an uncached
message >2 seconds (even 5 in worst case scenarios). Navigating roundcube
options, to have a comparison of the VM response times when IMAP is not
involved, need just 100-150 ms. Same timings for displaying cached messages.

But adding a proxy, so that connection to the imap server is kept for a
long time, is removing this delay. Which probably means imapd is actually
fast reading messages from the disk, or preloads them (no idea about this,
just a guess). So what probably is slow is the operations just after a user
login, does this makes sense? I have prefork set to 10 on imapd in
cyrus.conf I don't have much clues about how cyrus imap works, so any
advise to make it a little bit faster, in a 3 users scenario, is
appreciated.

Best regards
Enrico

On 16 September 2014 08:56, Enrico Tagliavini <enrico.tagliavini at gmail.com>
wrote:

> Hi Thomas,
>
> this happened in the past indeed, thank you for pointing this out. But
> since I switched from APC to APCU + zendopcache (which is part of upstream
> PHP and enabled by default since 5.5 IIRC) the problem gone away. I'll
> remove them if any segfault arise.
>
> On the performance side: having a cyrus local-listening-only IMAP server
> without TLS enabled (since if TLS is enabled roundcube will simply use it,
> regardless of the fact you put tls:// or not in the URI) helps, quite a
> bit. It is not blazing fast, but the first impression is a good
> improvement. Not as fast as with an IMAP proxy though, still need to read
> the cyrus manual a bit to se how can I enable debugging.
>
> Best regards
>
> Enrico
>
> On 15 September 2014 19:31, Thomas Spuhler <thomas.spuhler at btspuhler.com>
> wrote:
>
>> On Monday, September 15, 2014 01:22:37 PM Enrico Tagliavini wrote:
>> > Hi Daniel,
>> >
>> > no I didn't. MySQL doesn't seems to be the bottleneck to me. I tried to
>> > disable the cache entirely, or move to APC for imap_cache,
>>
>> Be careful using APC, you may just get very hidden segfaults resulting in
>> an empty screen
>>
>> > while keeping
>> > the imap proxy and performance is very good, if I ignore the issue about
>> > unread messages. If I disable the imap proxy roundcube goes back to
>> being
>> > slow. I can't explain this with a MySQL issue since it is unchanged
>> between
>> > my two config... to my knowledge at least. Also this is basically a
>> system
>> > with one or two users active at the same time at most.... it is not
>> loaded
>> > or the like. That said if I'm not able to explain it, it doesn't matter
>> > this is actually true.
>> >
>> > That said I'm very happy to try, but have not much idea how can I
>> improve
>> > MySQL performance. The server is running on the same VM, this is a
>> single
>> > host installation. Do you have some advise about how to improve it?
>> >
>> > FTR: I've php-pecl-apcu and php-pecl-zendopcache installed and enabled,
>> I
>> > forgot to include this information in the previous email. Dunno if it
>> > changes anything.
>> >
>> > Thank you
>> >
>> > Enrico
>> >
>> > On 15 September 2014 10:22, Daniel Hoffend <dh at dotlan.net> wrote:
>> > > Did you tried to improve the MySQL server which is used by roundcube
>> as
>> > > cache?
>> > >
>> > > --
>> > > mfg
>> > > Daniel Hoffend
>> > >
>> > > > Am 15.09.2014 um 09:59 schrieb Enrico Tagliavini <
>> > >
>> > > enrico.tagliavini at gmail.com>:
>> > > > 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
>> > > > _______________________________________________
>> > > > users mailing list
>> > > > users at lists.kolab.org
>> > > > https://lists.kolab.org/mailman/listinfo/users
>>
>> --
>> Best regards
>> Thomas Spuhler
>>
>> All of my e-mails have a valid digital signature
>> ID 60114E63
>> _______________________________________________
>> users mailing list
>> users at lists.kolab.org
>> https://lists.kolab.org/mailman/listinfo/users
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kolab.org/pipermail/users/attachments/20140919/28675c9b/attachment-0001.html>