<div dir="ltr">Mihai,<div><br></div><div>Can you explain:</div><div><br></div><div><span style="font-family:'Sans Serif';font-size:12px;white-space:pre-wrap">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</span><br></div><div><span style="font-family:'Sans Serif';font-size:12px;white-space:pre-wrap"><br></span></div><div><span style="font-family:'Sans Serif';font-size:12px;white-space:pre-wrap"><br></span></div><div>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.....<span style="font-family:'Sans Serif';font-size:12px;white-space:pre-wrap"><br></span></div><div><br></div><div>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.</div><div><br></div><div>Thanks guys!!</div><div><br></div><div>- Paul</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 8, 2015 at 3:14 AM, dsp3 <span dir="ltr"><<a href="mailto:info@dsp3.org" target="_blank">info@dsp3.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Here is the thread about poor Roundcube performance and disk I/O:<br>
<a href="http://lists.kolab.org/pipermail/users/2013-December/016063.html" rel="noreferrer" target="_blank">http://lists.kolab.org/pipermail/users/2013-December/016063.html</a><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<br>
On 2015-09-07 23:50, <a href="mailto:signaldeveloper@gmail.com" target="_blank">signaldeveloper@gmail.com</a> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Just curious - disk I/O as far as what for optimizations? As far as<br>
Cyrus I am at a halt as far as performance. It seems as though there<br>
isn't much as it is to optimize. I have been researching murder but I<br>
don't think that would help. Hell, I tried imapproxy and that didn't<br>
even help. Just with that constant login it killed speed. Oh well.<br>
Jump on the CC list for the bug if you'd have.<br>
<br>
Happy Labor Day!<br>
<br>
- Paul<br>
<br>
<br>
<br>
Sent from my iPhone<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Sep 7, 2015, at 4:41 PM, dsp3 <<a href="mailto:info@dsp3.org" target="_blank">info@dsp3.org</a>> wrote:<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 2015-09-07 23:12, <a href="mailto:signaldeveloper@gmail.com" target="_blank">signaldeveloper@gmail.com</a> wrote:<br>
Hey,<br>
Yah, I sent it to you directly also because I seen you were a part of<br>
some of the other threads from a while and I like to share things with<br>
people so I added you. Sorry about that.<br>
Also, I turned TLS off as a test to cut out the transaction time and<br>
some of the harder ciphers I have in place to see if that helped. It<br>
didn't. Plus having TLS on localhost when RC and Cyrus on same server<br>
is stupid IMHO. If you turn off TLS on kolab config and allow plain<br>
yet on Cyrus it will still generate the same as your logs just it will<br>
say PLAIN instead of TLS. I was just trying things out as I was<br>
getting desperate.<br>
Also, try turning those plugins off and just go through your messages.<br>
You may notice a huge difference :)<br>
A lot of people probably think their default install is fast (which<br>
it's not HORRIBLY slow) but disabling all of those plugins made things<br>
tremendously faster. And by things I mean just going through email in<br>
a folder.<br>
Try it out let me know if this goes well for you. I am interested to<br>
hear how the lists responds. I already got some feedback from others<br>
and they seem to find this works as well. Those entries in your log<br>
file are those plugins initiating a IMAP connection every time you<br>
simply hit into an email. This is not needed.<br>
Let me know how it goes!<br>
Paul<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Sep 7, 2015, at 4:01 PM, dsp3 <<a href="mailto:info@dsp3.org" target="_blank">info@dsp3.org</a>> wrote:<br>
Paul,<br>
I have Centos 6.7 Kolab 3.4 and I don't have these issues. Messages load fast.<br>
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?<br>
Example from my logs:<br>
Sep  7 15:55:58 kolab imap[21061]: USAGE <a href="mailto:info@dsp3.org" target="_blank">info@dsp3.org</a> user: 0.022996 sys: 0.000999<br>
Sep  7 15:56:28 kolab imap[21074]: starttls: TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits new) no authentication<br>
Sep  7 15:56:28 kolab imap[21074]: login: localhost [::1] <a href="mailto:info@dsp3.org" target="_blank">info@dsp3.org</a> PLAIN+TLS User logged in SESSIONID=<kolab.dsp3.org-221107-1441655788-1-00001111222233><br>
My $0.02<br>
ps - Your message didn't come from the kolab mailing list. This reply is to you and not on list.<br>
dsp3<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 2015-09-07 21:55, Paul Bronson wrote:<br>
Hi guys, (happy labor day!)<br>
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:<br>
A few kolab plugins are initiating an imap connection every time the user simply tries to read a message. Those plugins are:<br>
kolab_addressbook<br>
kolab_notes<br>
kolab_tags<br>
tasklist<br>
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:<br>
Sep 7 13:59:55 es1 imap[18657]: USAGE <a href="mailto:tperson@domain.info" target="_blank">tperson@domain.info</a> user: 0.004000 sys: 0.007999<br>
Sep 7 14:00:55 es1 imap[18657]: login: localhost [::1] <a href="mailto:tperson@domain.info" target="_blank">tperson@domain.info</a> PLAIN User logged in SESSIONID=<es1.domain.com-18657-1441648854-1-17261199637593060143><br>
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.<br>
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!<br>
I've logged a bug for this:<br>
<a href="https://issues.kolab.org/show_bug.cgi?id=5219" rel="noreferrer" target="_blank">https://issues.kolab.org/show_bug.cgi?id=5219</a> [1]<br>
Hopefully this will be an easy fix for the team!<br>
</blockquote>
Links:<br>
------<br>
[1] <a href="https://issues.kolab.org/show_bug.cgi?id=5219" rel="noreferrer" target="_blank">https://issues.kolab.org/show_bug.cgi?id=5219</a><br>
</blockquote></blockquote></blockquote></blockquote>
</div></div></blockquote></div><br></div>