Poor Roundcube performance with default configuration

[Enrico Tagliavini]

Thank you that's useful to know, however that page says you must keep
synchronous mode for ext2fs, while with any other newer file system (a
very relative concept) the synchronous mode should not be necessary.
It would be nice to have some more details on that, like why ext2
needs to be sync and newer file systems do not. The only reason I can
think of is ext2 is not journaled (which makes sense to me).

The kolab documentation doesn't talk about journal or file system
specific notes, it talks about battery backed cache, which has nothing
to do with sync mode. That's what confused me, the kolab doc is, in my
humble opinion, wrong with the argument about battery backed cache and
should probably be replaced with journaled file system. Anybody
disagree with this?

Best regards.
Enrico


On 3 February 2015 at 17:24, Christian Hügel
<christian.huegel at stonebyte.de> wrote:
> Please see this doc [1] at paragraph 9
>
> [1] https://cyrusimap.org/docs/cyrus-imapd/2.4.7/install-configure.php
>
> Am 03.02.2015 um 17:13 schrieb Enrico Tagliavini:
>> Why for ext2 and ext3 you should be able to disable it? They are no
>> special when it comes to power loss. Yes the commit is forced every 5
>> seconds, and that's more than enough to corrupt stuff.
>>
>> Other than that I would keep the sync enabled anyway since you might
>> have a battery backed cache on the drive / controller, but if the
>> write cache of your OS file system is lost well that's still not good.
>> What you can turn off to increase performance, if you have a battery
>> backed cache, are block level write barriers.
>>
>> However what I'm saying is valid in general, no idea if cyrus-imapd
>> ensures some level on consistency by other means (like calling fsync()
>> when needed instead of doing every single write in sync mode). But I
>> still can't see any way why ext2 and ext3 would let you disable the
>> sync safely.
>>
>> Best regards.
>> Enrico
>>
>> On 3 February 2015 at 16:23, Christian Hügel
>> <christian.huegel at stonebyte.de> wrote:
>>> The issue with the poor performance is the "Synchronous File Operations" [1]
>>> For a ext2/ext3 file system you can turn this off
>>>
>>>
>>> [1] https://docs.kolab.org/administrator-guide/tweaking-cyrus-imapd.html
>>>
>>>
>>>
>>> Am 17-03-2014 21:27, schrieb Christian Hügel:
>>>>
>>>> This is the same observation I have made with roundcube [1] I even went
>>>> so far installing a imapproxy to improve somehow the webinterface.
>>>>
>>>>
>>>> [1] http://lists.kolab.org/pipermail/users/2013-December/016164.html
>>>>
>>>> Am 17.03.2014 21:12, schrieb Brady, Mike:
>>>>>
>>>>> Mileage may well vary on this one but I thought that others may be
>>>>> interested in this observation.
>>>>>
>>>>> With a default configuration of Kolab 3.1 on a single Centos 6.5 box I
>>>>> have found Roundcube performance to be not great.
>>>>>
>>>>> By default configuration I mean nothing more than
>>>>>
>>>>> yum install kolab
>>>>> setup-kolab
>>>>>
>>>>> has been done.
>>>>>
>>>>> I have found that disabling imap_cache and messages_cache significantly
>>>>> improves Roundcube performance.  These settings can be found in
>>>>> /etc/roundcube/config.inc.php.  I notice that what I assume to be the
>>>>> Roundcube defaults in /etc/roundcube/defaults.inc.php is for these to be
>>>>> disabled.
>>>>>
>>>>> Tuning mysql (which I haven't done) may well improve things, but I have
>>>>> to wonder if it is worth the additional overhead of running a mysql
>>>>> cache for Roundcube with a default all in one installation of the Kolab
>>>>> components?
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> Regards
>>>>>
>>>>> Mike
>>>>> _______________________________________________
>>>>> 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
>>>
>>>
>>> _______________________________________________
>>> users mailing list
>>> users at lists.kolab.org
>>> https://lists.kolab.org/mailman/listinfo/users
>
> --
> GPG-Key: 1F814CFD
>