If you want a faster Kolab, read this.

[Christian Hügel]

OK, i got you right now :) You mentioned a performance boost using
memcached. Can you point me a documentation enabling this?
Thanks

Am 08.09.2015 um 17:54 schrieb signaldeveloper at gmail.com:
> Christian,
> 
> Obviously. This is meant more as a bug test case not as a fix.
> 
> 
> 
>> On Sep 8, 2015, at 11:46 AM, Christian Hügel <christian.huegel at stonebyte.de> wrote:
>>
>> I also have a major performance problem although with kolab 3.2 but I do
>> not see the point in deactivating those plugins; it would´ t be a kolab
>> server anymore instead just an ordinary imap server. So this workaround
>> is a "no go"
>>
>> Cheers,
>>
>> Christian
>>
>>> Am 07.09.2015 um 20:55 schrieb Paul Bronson:
>>> 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
>>> <mailto: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 <mailto: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
>>>
>>>
>>> Hopefully this will be an easy fix for the team!
>>>
>>>
>>>
>>> _______________________________________________
>>> users mailing list
>>> users at lists.kolab.org
>>> https://lists.kolab.org/mailman/listinfo/users
>>
>> -- 
>> GPG-Key: 1F814CFD
>>
>> _______________________________________________
>> 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  : 836 bytes
Beschreibung: OpenPGP digital signature
URL         : <http://lists.kolab.org/pipermail/users/attachments/20150908/160ddf10/attachment.sig>