Roundcube performance

[Enrico Tagliavini]

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 listusers at lists.kolab.orghttps://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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kolab.org/pipermail/users/attachments/20140919/92960b3d/attachment.html>