Roundcube performance

Christian Hügel christian.huegel at stonebyte.de
Mon Jan 12 20:29:45 CET 2015 

Hey Enrico,

thank you for your thoughts. Yes I have a multidomain environment with 8
domains and about 50 users so, as you said I'll import all data to a VM
and thest the upgrade.

Thank you.

Cheers

Christian

Am 12.01.2015 um 20:08 schrieb Enrico Tagliavini:
> Hi Christian,
> 
> well I don't have to be brave at all. I have three users, and 95% of
> the time is me alone. It is my family mail server eheheh. So no,
> single domain only, at least for now.
> 
> I followed this guide, with very minor adaptations
> https://docs.kolab.org/administrator-guide/upgrading-from-kolab-3.1-to-3.3.html
> 
> Other than the mailbox reconstruct, I also reverted back chwala URL to
> be forced https. I run kolab behind a reverse proxy also applying TLS
> and chwala never worked at its best in this condition (if you have
> HSTS on at least). And even this way the preview of a file doesn't
> work since the html is generated with http:// links in it. I don't
> really care about it TBO.
> 
> Other than what I mentioned I just crawled a bit in the git logs and
> diff between revisions to check all the changed config, but the guide
> itself already mention all of the relevant changes, so I simply double
> checked. The only annoying problem I had is that the release repo (not
> the update one) has few packages signed with an unknown key. This is
> very annoying since I had to turn off GPG check for the repo to
> update.
> 
> If the better performance is not pushing you enough, and I understand
> it, security probably should. Roundcube 1.0.x with x < 4 has a
> security bug mentioned on the official website:
> http://roundcube.net/news/2014/12/18/update-1.0.4-released/
> 
> I cannot really judge how important this update is since I have not
> much time to check it out, and I updated already so.... but still CSRF
> doesn't sound good.
> 
> On the other end I can see quite a few mail about kolab and
> multidomain problems.... I can understand you fear. You can solve it
> by duplicating production into a testing system and try to update that
> first.....
> 
> Best regards and good luck.
> 
> Enrico
> 
> On 12 January 2015 at 19:05, Christian Hügel
> <christian.huegel at stonebyte.de> wrote:
>> Hi,
>> Thank you for your information. Can you provide the upgrade path from 3.2 to
>> 3.3? Did you encounter any problems? Do you use a multidomain environment?
>> I'm thinking of upgrading too but to be honest I'm not so brave like that at
>> the moment.
>> Thx
>>
>>
>>
>> Am 12. Januar 2015 18:08:51 schrieb Enrico Tagliavini
>> <enrico.tagliavini at gmail.com>:
>>
>>
>>> 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
>>>>
>>>>
>>> _______________________________________________
>>> users mailing list
>>> users at lists.kolab.org
>>> https://lists.kolab.org/mailman/listinfo/users
>>
>>
>>

-- 
GPG-Key: 1F814CFD

-------------- n�chster Teil --------------
Ein Dateianhang mit Bin�rdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigr��e  : 819 bytes
Beschreibung: OpenPGP digital signature
URL         : <http://lists.kolab.org/pipermail/users/attachments/20150112/72fbd242/attachment-0001.sig>

More information about the users mailing list