Roundcube performance

[Enrico Tagliavini]

Hello everyone,

sorry for resuming a very very old thread, but I might have some
interesting (and positive) news. One week ago I updated to Kolab 3.3,
from 3.2. Well my experience improved dramatically:

What goes faster: switching directory (so directory listing), checking
for new mail, marking mail as read, going from one tool to another
(mail, calendar and so on).

What is still slow: opening a non cached message, but this was the
less annoying part in my honest opinion. And it is not so terribly
slow. When I click on a message not in cache it takes about 0.6-0.9
seconds for the request to be processes and another 0.2-0.3 to get
additional content of the page (usually in the browser cache anyway),
with some unluck case where the first GET request takes 2 full
seconds. I also noticed chattr -R +S is run on imap directories and is
taking forever to complete, but I guess +S is a safety measure not to
have a corrupted mailbox, so I don't even try removing it. Running
standard HDDs (2 standard SATA disks in RAID 1) without cache is not
really optimal for sync write performance. I could try some ram cache
(like dm-cache), but I'm quite worried I would end up with corrupted
data if something bad happens.

So other than upgrading to roundcube 1.1 from 1.0, and cyrus-imap pre
release, what else changed? Well I was forced the reconstruct all
mailboxes, due to the notes plugin not working. It was complaining
about missing indexes (in maillog). So I did

 for mb in $(kolab lm); do /usr/lib/cyrus-imapd/reconstruct -r -f $mb; done

I have no idea at all if this could have affected the performance in
any way. This installation of kolab started with 3.0 not much time
after the release, I have no idea if something gone rotten in the way.

Well anyway it is way better with Kolab 3.3 so I'm very very happy I upgraded.

Thank you for all the work and the support.

Best regards.

Enrico

On 19 September 2014 at 20:15, Enrico Tagliavini
<enrico.tagliavini at gmail.com> wrote:
> Hi Friedemann,
>
> as I said in previous mails, imapproxy was indeed improving performance
> quite a bit, but unfortunately it breaks roundcube for me, as in unread
> messages are no more displayed when using imapproxy.
>
> With some recent, after my last message, optimization at VM level (enabled
> Linux aio and removed the cache for virtio disk), and still with TLS
> disabled (totally fine since roundcube and imapd are still on the same
> host), I can see not much difference anymore between with and without proxy.
> Still message refresh / load / listing is very slow, almost always over 2
> seconds.
>
> I will try what Toke suggested, but I have not much hope to be honest. I was
> aware of those 2 directories, but I don't think it makes any difference for
> an almost single user imap server.... IOops should not to be a limiting
> factor when you have a only one active user 95% of the time.
>
> Anyway thank you to you both for you suggestions, being very short on ideas
> any help is very appreciated.
>
> Best regards
> Enrico
>
>
> On 19 September 2014 19:44, Friedemann Schorer <friedemann at schorers.org>
> wrote:
>>
>> Just joined the list, so please excuse me if this has been mentioned
>> before. Debian and Ubuntu have a package called imapproxy. I installed it
>> and had roundcube use it and that dramatically speeded things up because
>> roundcube frequently logs in and out of the IMAP server, which takes a lot
>> of time, and imapproxy just opens one connection the the imap server and
>> keeps it open.
>>
>> Maybe it's worth a try, I had very positive experiences with it.
>>
>>
>>
>> Best regards,
>>
>>
>>
>> Friedemann
>>
>>
>>
>> Am 19.09.2014 18:45, schrieb Toke Høiland-Jørgensen:
>>
>> Enrico Tagliavini <enrico.tagliavini at gmail.com> writes:
>>
>> 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.
>>
>> This sounds like it might be related to the 'lock' and 'proc' files that
>> cyrus-imapd creates on every user login. I seem to recall having
>> horrible performance because of that at some point.
>>
>> Basically, imapd creates a pid file in /var/lib/imap/proc on every
>> login, and a lock file in /var/lib/imap/lock on every folder access. If
>> the server is IOPS-limited this can cause large delays. The solution (if
>> this is indeed what you're experiencing) is to move these directories to
>> tmpfs; either symlink them into an existing tmpfs (such as /dev/shm or
>> /tmp depending on your setup), or stick this in your /etc/fstab:
>>
>> none /var/lib/imap/proc tmpfs defaults 0 0
>> none /var/lib/imap/lock tmpfs defaults 0 0
>>
>> and then mount the directories.
>>
>>
>> -Toke
>>
>>
>> _______________________________________________
>> users mailing list
>> users at lists.kolab.org
>> https://lists.kolab.org/mailman/listinfo/users
>>
>>
>>
>> --
>> Psst - nutzt Du auch schon Bitcoins?
>> Hier ist eine der sichersten Bitcoin-Börsen zu finden:
>> https://www.bitcoin.de/de/r/cwz44t
>>
>>
>> _______________________________________________
>> users mailing list
>> users at lists.kolab.org
>> https://lists.kolab.org/mailman/listinfo/users
>
>