If you want a faster Kolab, read this.

Tue Sep 8 14:55:21 CEST 2015

Mihai,

Can you explain:

But i think there is something wrong with the cache for those modules. All
imap data are cached in sql. My guess is you have some fields missing in
sql cache tables and roundcube is forced to read from imap

Where can I find this or test it? Kolab is suggesting this is done to check
cache, but I am not sure why it needs to check cache for the tasklist
notes, etc when a user is simply browsing their email and not even using
this option? I don't see any errors in any error logs either.....

DSP3 = I have read over this many times :) I really doubt this is a IO
problem. I have many other installs running on this same equipment that
runs beautifully.

Thanks guys!!

- Paul

On Tue, Sep 8, 2015 at 3:14 AM, dsp3 <info at dsp3.org> wrote:

> Here is the thread about poor Roundcube performance and disk I/O:
> http://lists.kolab.org/pipermail/users/2013-December/016063.html
>
>
>
>
> On 2015-09-07 23:50, signaldeveloper at gmail.com wrote:
>
>> Just curious - disk I/O as far as what for optimizations? As far as
>> Cyrus I am at a halt as far as performance. It seems as though there
>> isn't much as it is to optimize. I have been researching murder but I
>> don't think that would help. Hell, I tried imapproxy and that didn't
>> even help. Just with that constant login it killed speed. Oh well.
>> Jump on the CC list for the bug if you'd have.
>>
>> Happy Labor Day!
>>
>> - Paul
>>
>>
>>
>> Sent from my iPhone
>>
>> On Sep 7, 2015, at 4:41 PM, dsp3 <info at dsp3.org> wrote:
>>>
>>> Interesting observations. TBH, my messages load as fast as I blink and
>>> that's plenty for my old tired eyes :) The speed bottleneck on my install
>>> is the remote location, but I'd be interested to see how this plays out on
>>> a local install.
>>>
>>> There have been lots of optimization discussions in the past, mainly
>>> concerning disk I/O, so I'll keep an eye on these developments and will be
>>> interested in the responses to the ticket.
>>>
>>> As an aside, I do have a local server running different webmail
>>> (Nginx/Rainloop) and IMAP backend. Whilst it is faster to load messages,
>>> the difference isn't that great.
>>>
>>>
>>> On 2015-09-07 23:12, signaldeveloper at gmail.com wrote:
>>>> Hey,
>>>> Yah, I sent it to you directly also because I seen you were a part of
>>>> some of the other threads from a while and I like to share things with
>>>> people so I added you. Sorry about that.
>>>> Also, I turned TLS off as a test to cut out the transaction time and
>>>> some of the harder ciphers I have in place to see if that helped. It
>>>> didn't. Plus having TLS on localhost when RC and Cyrus on same server
>>>> is stupid IMHO. If you turn off TLS on kolab config and allow plain
>>>> yet on Cyrus it will still generate the same as your logs just it will
>>>> say PLAIN instead of TLS. I was just trying things out as I was
>>>> getting desperate.
>>>> Also, try turning those plugins off and just go through your messages.
>>>> You may notice a huge difference :)
>>>> A lot of people probably think their default install is fast (which
>>>> it's not HORRIBLY slow) but disabling all of those plugins made things
>>>> tremendously faster. And by things I mean just going through email in
>>>> a folder.
>>>> Try it out let me know if this goes well for you. I am interested to
>>>> hear how the lists responds. I already got some feedback from others
>>>> and they seem to find this works as well. Those entries in your log
>>>> file are those plugins initiating a IMAP connection every time you
>>>> simply hit into an email. This is not needed.
>>>> Let me know how it goes!
>>>> Paul
>>>>
>>>>> On Sep 7, 2015, at 4:01 PM, dsp3 <info at dsp3.org> wrote:
>>>>> Paul,
>>>>> I have Centos 6.7 Kolab 3.4 and I don't have these issues. Messages
>>>>> load fast.
>>>>> I notice you have no TLS in your IMAP logins from localhost? The
>>>>> default is to have TLS enabled I believe. Could this be the source of your
>>>>> observations?
>>>>> Example from my logs:
>>>>> Sep  7 15:55:58 kolab imap[21061]: USAGE info at dsp3.org user: 0.022996
>>>>> sys: 0.000999
>>>>> Sep  7 15:56:28 kolab imap[21074]: starttls: TLSv1 with cipher
>>>>> ECDHE-RSA-AES256-SHA (256/256 bits new) no authentication
>>>>> Sep  7 15:56:28 kolab imap[21074]: login: localhost [::1]
>>>>> info at dsp3.org PLAIN+TLS User logged in
>>>>> SESSIONID=<kolab.dsp3.org-221107-1441655788-1-00001111222233>
>>>>> My $0.02
>>>>> ps - Your message didn't come from the kolab mailing list. This reply
>>>>> is to you and not on list.
>>>>> dsp3
>>>>>
>>>>>> On 2015-09-07 21:55, Paul Bronson wrote:
>>>>>> Hi guys, (happy labor day!)
>>>>>> As you've probably seen me asking a thousand questions about slowness
>>>>>> for my brand new kolab 3.4, here's what my few weeks of research has come
>>>>>> up with... And hopefully this will work for all of you as well, or
>>>>>> something you can try and replicate on your end:
>>>>>> A few kolab plugins are initiating an imap connection every time the
>>>>>> user simply tries to read a message. Those plugins are:
>>>>>> kolab_addressbook
>>>>>> kolab_notes
>>>>>> kolab_tags
>>>>>> tasklist
>>>>>> If you disable ALL (not one) of these plugins, watch how magically
>>>>>> fast clicking on a message is. You will also notice logs in your
>>>>>> var/log/maillog such as this disappear:
>>>>>> Sep 7 13:59:55 es1 imap[18657]: USAGE tperson at domain.info user:
>>>>>> 0.004000 sys: 0.007999
>>>>>> Sep 7 14:00:55 es1 imap[18657]: login: localhost [::1]
>>>>>> tperson at domain.info PLAIN User logged in
>>>>>> SESSIONID=<es1.domain.com-18657-1441648854-1-17261199637593060143>
>>>>>> These above log entries will however happen when you go to different
>>>>>> folders, but simply just single clicking a message to see it on the preview
>>>>>> pane will no longer log the entry.
>>>>>> I have also seen a HUGE improvement from memcache as well. (now that
>>>>>> instead of opening a new connection, it can now actually check against
>>>>>> memcache for a cache'd version) I also went to vast lands to try to make
>>>>>> cyrus faster thinking that was the problem, but I think this was the key!
>>>>>> I've logged a bug for this:
>>>>>> https://issues.kolab.org/show_bug.cgi?id=5219 [1]
>>>>>> Hopefully this will be an easy fix for the team!
>>>>>>
>>>>> Links:
>>>>> ------
>>>>> [1] https://issues.kolab.org/show_bug.cgi?id=5219
>>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kolab.org/pipermail/users/attachments/20150908/6c910f61/attachment.html>