<div dir="ltr"><div><div>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.<br><br></div>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.<br><br></div><div>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.<br><br></div><div>Best regards<br></div><div>Enrico<br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 16 September 2014 08:56, Enrico Tagliavini <span dir="ltr"><<a href="mailto:enrico.tagliavini@gmail.com" target="_blank">enrico.tagliavini@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div>Hi Thomas,<br><br></div>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.<br><br></div>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.<br><br></div>Best regards<span class="HOEnZb"><font color="#888888"><br><br></font></span></div><span class="HOEnZb"><font color="#888888">Enrico<br></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On 15 September 2014 19:31, Thomas Spuhler <span dir="ltr"><<a href="mailto:thomas.spuhler@btspuhler.com" target="_blank">thomas.spuhler@btspuhler.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Monday, September 15, 2014 01:22:37 PM Enrico Tagliavini wrote:<br>
> Hi Daniel,<br>
><br>
> no I didn't. MySQL doesn't seems to be the bottleneck to me. I tried to<br>
> disable the cache entirely, or move to APC for imap_cache,<br>
<br>
</span>Be careful using APC, you may just get very hidden segfaults resulting in an empty screen<br>
<div><div><br>
> while keeping<br>
> the imap proxy and performance is very good, if I ignore the issue about<br>
> unread messages. If I disable the imap proxy roundcube goes back to being<br>
> slow. I can't explain this with a MySQL issue since it is unchanged between<br>
> my two config... to my knowledge at least. Also this is basically a system<br>
> with one or two users active at the same time at most.... it is not loaded<br>
> or the like. That said if I'm not able to explain it, it doesn't matter<br>
> this is actually true.<br>
><br>
> That said I'm very happy to try, but have not much idea how can I improve<br>
> MySQL performance. The server is running on the same VM, this is a single<br>
> host installation. Do you have some advise about how to improve it?<br>
><br>
> FTR: I've php-pecl-apcu and php-pecl-zendopcache installed and enabled, I<br>
> forgot to include this information in the previous email. Dunno if it<br>
> changes anything.<br>
><br>
> Thank you<br>
><br>
> Enrico<br>
><br>
> On 15 September 2014 10:22, Daniel Hoffend <<a href="mailto:dh@dotlan.net" target="_blank">dh@dotlan.net</a>> wrote:<br>
> > Did you tried to improve the MySQL server which is used by roundcube as<br>
> > cache?<br>
> ><br>
> > --<br>
> > mfg<br>
> > Daniel Hoffend<br>
> ><br>
> > > Am 15.09.2014 um 09:59 schrieb Enrico Tagliavini <<br>
> ><br>
> > <a href="mailto:enrico.tagliavini@gmail.com" target="_blank">enrico.tagliavini@gmail.com</a>>:<br>
> > > Hello everyone,<br>
> > ><br>
> > > I was wondering if anybody has some suggestion on how to make roundcube<br>
> ><br>
> > in kolab 3.2 (and 3.3 as well since I plan to upgrade before Christmas I<br>
> > hope) a little bit faster.<br>
> ><br>
> > > Prologue: in kolab 3.0 and 3.1 roundcube was not very fast.... but still<br>
> ><br>
> > acceptable. Updated to kolab 3.2 and, while roundcube interface is better,<br>
> > prettier than before it is also slower (no idea if updat of cyrus imap can<br>
> > be blamed as well but I don't think so). Slower to the point of being<br>
> > annoying.<br>
> ><br>
> > > My config: this is a 3 users system, nothing big. spool/imap is about<br>
> ><br>
> > 118 MB with about 12000 files. I first installed this with kolab 3.0 a<br>
> > couple of years ago and updated it as new releases where coming out. The<br>
> > system runs on a VM, with 2 vcores and 3 GB of ram. The host is under my<br>
> > direct control and fr the reference it is a SYS from OVH. Host processor is<br>
> > a Xeon E3-1225 with 32 GB of ram, with an average use of cpu time under 5%<br>
> > according to munin. The 2 hard drives are in software raid one on the host,<br>
> > and the disk image for the kolab VM is an LVM logical volume passed<br>
> > directly to the VM. The hypervisor is KVM, OS is CentOS 6.5 both on host<br>
> > and guest. The file system for the imap folders is the same has /, with<br>
> > stock ext4 options. For such a small spool I don't think separating it<br>
> > would make much difference, but feel free to correct me and suggest better<br>
> > settings.<br>
> ><br>
> > > To quantify slow in roundcube I would say that opening an uncached<br>
> ><br>
> > message takes an average time of 2-4 seconds (according to firefox network<br>
> > console / firebug), refresh can take even more sometimes. Switching folder<br>
> > is the same. In some rare cases some operation can reach 10 seconds, but<br>
> > this is quite rare. This is not network latency since it happens also from<br>
> > work networks. From work I have access to two networks, one is a 100 mbit<br>
> > eth, the second is 1gbit eth. Average latency to my server is about 13ms ±<br>
> > 0.2, measured with both ping (average in 50 samplings) and mtr.<br>
> ><br>
> > > I have no clue what could be the bottleneck, the only symptom I can see,<br>
> ><br>
> > other than the slow speed, is a lot of I/O wait in the kolab VM, likely<br>
> > from imapd. Munin confirms that from kolab 3.1 to kolab 3.2 the cpu I/O<br>
> > wait time increased quite a bit. I would roughly say it is doubled, from<br>
> > ~2% to 3-4%. But it is hard to say since the values are small. Anyway I can<br>
> > see the I/O wait clearly with htop while refreshing or opening uncached<br>
> > messages. I can't be sure if this I/O is from disk or from network. For<br>
> > both I use virtio. For the disk I switched to virtio SCSI just to see if it<br>
> > was making any difference.<br>
> ><br>
> > > So far I've tried to add imapproxy between roundcube and cyrus-imap. I<br>
> ><br>
> > had to do some odd config here since roundcube will refuse to connect to<br>
> > anything else that localhost:143, ignoring whatever I put into the config<br>
> > file (I tried to put imapproxy on 144 at the beginning, this bug has been<br>
> > reported in roundcube in the past already). So I moved cyrus-imap and bound<br>
> > it to the external IP only and got imapproxy on 127.0.0.1 only.<br>
> ><br>
> > > With imapproxy the roundcube performance increase dramatically, but<br>
> ><br>
> > unfortunately the unread messages display is broken. The unread message<br>
> > cunt on the left is correct, but I have to force the view to unread<br>
> > messages only to actually be able to see them. Just opening a folder with<br>
> > uncached unread messages lists only the cached one (what you already read)<br>
> ><br>
> > :(. I've tried to disable caching in roudcube, both for messages and imap,<br>
> ><br>
> > the result seem the same oddly. I'll keep it disabled for a while and see<br>
> > if the behaviour changes. I saw an old bug report for roundcube describing<br>
> > this behaviour, but can't find it again right now... sorry.<br>
> ><br>
> > > So my question is what can I do to speed up roundcube a bit without<br>
> ><br>
> > breaking it.<br>
> ><br>
> > > Also, as a suggestion to Kolab developers: I think investigating the<br>
> ><br>
> > possibility of adding imap proxy caching to kolab would be very worth it,<br>
> > if you didn't already. Performance gain is massive. Provided it doesn't<br>
> > break roundcube itself like in my case of course. I'm not aware of any<br>
> > other imap proxy other than the squirrel mail one.... tried with nginx but<br>
> > it want to do fancy stuff for the authentication so I didn't even tried it.<br>
> ><br>
> > > Thank you.<br>
> > > Best regards<br>
> > ><br>
> > > Enrico<br>
> > > _______________________________________________<br>
> > > users mailing list<br>
> > > <a href="mailto:users@lists.kolab.org" target="_blank">users@lists.kolab.org</a><br>
> > > <a href="https://lists.kolab.org/mailman/listinfo/users" target="_blank">https://lists.kolab.org/mailman/listinfo/users</a><br>
<br>
</div></div><span><font color="#888888">--<br>
Best regards<br>
Thomas Spuhler<br>
<br>
All of my e-mails have a valid digital signature<br>
ID 60114E63</font></span><br>_______________________________________________<br>
users mailing list<br>
<a href="mailto:users@lists.kolab.org" target="_blank">users@lists.kolab.org</a><br>
<a href="https://lists.kolab.org/mailman/listinfo/users" target="_blank">https://lists.kolab.org/mailman/listinfo/users</a><br></blockquote></div><br></div>
</div></div></blockquote></div><br></div>