If you want a faster Kolab, read this.

[Brady, Mike]

On 2015-09-14 16:15, Brady, Mike wrote: 

> Paul 
> 
> On 2015-09-13 12:31, Paul Bronson wrote: 
> 
> It's odd because only (not in front of me right now) a few of the actual kolab plugins check in EVERY message select. If you disable them, the system runs super fast. I watch as the plugin check in on SQL but they also check in with IMAP. I'm not sure what else to do but the Cyrus guys are telling me kolab may have compiled their SASL not too smart. 
> What is it that they think is wrong exactly or at least in what area do they think that there is an issue?

They're telling me the multiple check-in's with IMAP is costly. I am not
a imap dev, sorry - didn't get much more than that. Another guy
suggested cache wasn't working right, but I watch things update
everywhere they're supposed to regarding cache (especially in the kolab
cache mysql table) so that looks well. The Mysql log shows a ton going
on for a SINGLE message click. Look at the mysql logs I provided. 

Yes IMAP connections are costly. You need to do anything and everything
to make them cost the least that you can because they are going to
happen at some point no matter what you do because that is where the
data is. As I have said before, for me the two changes directly
connected to making an IMAP connection that made a (subjective)
difference are adding $config['imap_auth_type'] = 'PLAIN' to
/etc/roundcube/config.inc.php and disabling TLS for localhost
connections. 

I did try an imapproxy a while ago, but did not perceive any
improvement. I may give that another try now that I know how to measure
my response times (see below). 

> At this point I am hoping to hear something from these guys about what's going on. 
> Mike - have you tried following my steps in the bug? You may see a difference just disabling the few plugins (testing obviously, not permanent). Just following the steps I provided and see what happens. 
> I have not tried this because, as I have said before, I do not see this behaviour at all.

You (as many others) may not think your install is slow, but I am
telling you, just go in, disable the plugins I have explained, and give
it a shot. Watch your message load increase by 10x. Christian (CC'ed)
tried this, and it worked awesome for him as well. Of course this isn't
perfect/permanent and you can simply re-enable the plugins, nothing will
happen to your install. I would at least try it and you'll see what I am
talking about. Maybe you just aren't used to the fast actions on mail
servers like I am. Give it a shot. 

To be more specific: 

>> With the preview pane enabled, if I select (meaning one click) a message that is not in the cache I see two logins. Using tshark on the Kolab server it looks like one login fetches the message and one login accesses the Configuration folder. That is all. I have never seen "one login per plugin" (which is what I believe you are saying that you are seeing) when selecting an email. The configuration folder is where tags are kept and if there are entries in that folder there will be some searches done within the session for tags. 
>> Subjectively (I must find out how to get some actual timings), from the time that I click on a email to the time it is displayed in the preview pane is about one second. Maybe a little more sometimes. I would love to get my message display times to be consistently < 1sec

My subjective 1 second for viewing an email was out a bit. Doing some
tests today, according to Google Chrome Inspect Element, my response
time for the selection and viewing of an email in the preview pane is
consistently around 550ms and that is over a 1Mbit link. I will test on
a network local to the server when I get the chance. This was with
accessing Roundcube over HTTPS and with all plugins enabled, except the
files plugin as I do not use this and it had some issues a while back so
I have it disabled. 

> I am going to say user and sys on USAGE is probably the timing numbers to go against. Let's see what cyrus guys CCed on this have to say. 
> 
> Cyrus guys blamed SASL but also wondered why my entropy was so low. I've done a lot of research over the past few weeks learning about entropy generation and it seems on a normal server it seems to be normal to have 1000 something.. Even on a headless server. My other production servers only have 180 and they're lightning fast. So I'm confused. 
> 
> My entropy is no better than yours, but it could still be a contributing factor.

What's your entropy at? Is it headless? 

>From the quick look that I had last week my entropy was somewhere around
150-200. I installed haveged a couple of days ago and now the entropy is
consistently >2000, but I do not believe that it has made any difference
and I may well remove it.

My Kolab server is a Centos 6.6 KVM virtual machine on a Centos 6.7
host. The host is headless. I am hoping to get the virtual machine
migrated to Centos 7.1 on the same host this week. 

>> I do not think that there is a single setting that is going to suddenly make Kolab perform. It is going to be the sum of a lot of things starting with the hardware and working up. Every little bit is going to help.

I have to reiterate this. No one thing has given me the performance that
I have. Everything from your hard disk configuration up on through your
Apache configuration and all points in between is going to contribute to
your performance (or the lack there of). 

Regards 

Mike 

Paul 

Quick test (only checked with a few different messages) this morning
from a network segment on the same site (routed via virtual pfSense on
the same host) gives times consistently less than 400ms. 

Yesterdays tests were over an OpenVPN connection to the same pfSense
mentioned above. 

This was using the same laptop as a client with the timings coming from
Google Chrome Inspect Element again. One thing that Google Chrome
Inspect Element shows is that the browser cache plays a big role in this
performance as it caches all the css and js that is fetched on every
email selection. 

Is <400ms slow? 

Regards 

Mike 

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kolab.org/pipermail/users/attachments/20150915/ee492029/attachment.html>