Connect. Communicate. Collaborate. Securely.

Home » Kerio User Forums » Kerio Connect » Speed increase - Outlook Connector
  •  
Michael Ruffin

Messages: 172
Karma: 4
Send a private message to this user
I know this has been asked countless times before, but thought I'd bring up this old nugget again.

Is there any work being done on increasing the speed of the Kerio Outlook Connector, or even better, a new version that doesn't require client-side caching?

I love all the new features that are being added to Kerio Connect, but to be quite honest, I think a majority of our clients would prefer a faster Outlook Connector.
  •  
Vicky

Messages: 656

Karma: 81
Send a private message to this user
Hi Michael,

I'm sure you have seen this article before:

http://kb.kerio.com/204

At the moment this is the best thing we can offer customers. I have always found that a maintained mailbox is the key to the speed, as long as each folder has less then 10,000 items in it really does help. That and making sure not 3rd party pluggins are running. That's my 2 cents anyway.

I hope the above helps,
Vicky
  •  
Bud Durland

Messages: 387
Karma: 42
Send a private message to this user
Vicky -- you are right that mailbox maintenance is important, but the performance gain there is not near what could be. As a test, I setup an OutLook profile to access my mail store via IMAP and it was significantly faster accessing e-mails. Of course, you lose access to calendars and shared contacts, unless you're OK with read-only LDAP.

When we started moving our users to Office 2010, and were therefore forced to use the off-line connector, is when the majority of my performance complaints started.
  •  
Michael Ruffin

Messages: 172
Karma: 4
Send a private message to this user
Yes I have read all the recommendations by Kerio about how to speed up Outlook, but unfortunately some of our clients have rather large mailboxes (some are around 30-40GB each), and they don't see *why* they should have to 'clean up' their inbox, when performance was just fine under Exchange.

It's also hard to defend when search performance on webmail is blisteringly fast compared to searching through Outlook. I know there's a difference between the two, but a nicely made non-caching version of the Outlook Connector, that supports contacts/calendars etc. would be a godsend right about now.
  •  
Michael Ruffin

Messages: 172
Karma: 4
Send a private message to this user
Vicky Cinelli (Kerio) wrote on Wed, 12 August 2015 23:53
Hi Michael,

At the moment this is the best thing we can offer customers.



I'm not trying to be a pain, but does this mean that Kerio aren't actively looking at speeding up the Outlook Connector?

I'd be happy if we were told that something was being looked at, and to wait, but it seems that from all the responses from Kerio, that you believe that the speed of the connector is sufficient (even though this seems to be the most complained about part of Connect).
  •  
zebby

Messages: 234
Karma: 1
Send a private message to this user
Michael Ruffin wrote on Wed, 12 August 2015 22:48
Vicky Cinelli (Kerio) wrote on Wed, 12 August 2015 23:53
Hi Michael,

At the moment this is the best thing we can offer customers.



I'm not trying to be a pain, but does this mean that Kerio aren't actively looking at speeding up the Outlook Connector?

I'd be happy if we were told that something was being looked at, and to wait, but it seems that from all the responses from Kerio, that you believe that the speed of the connector is sufficient (even though this seems to be the most complained about part of Connect).


I hope this isn't the case.
Since we moved from Office 2010 to Office 2013 the performance of the Outlook Connector is dreadful.
Startup times are several seconds while koffbackend.exe disk thrashes it's way through FDB files. Even when it's calmed down an email will hit my phone several seconds before it appears in Outlook!

So please tell me you are still working on the Outlook Connector....
  •  
MarkK

Messages: 454
Karma: 46
Send a private message to this user
Isn't That what the "Kerio Outlook Connector (without offline caching)" does? No local cache, all work done on the server? It is still being kept up so that it works, though it is missing some of the other advantages of the KOFF connector.
  •  
Bud Durland

Messages: 387
Karma: 42
Send a private message to this user
MarkK wrote on Fri, 14 August 2015 17:06
Isn't That what the "Kerio Outlook Connector (without offline caching)" does? No local cache, all work done on the server? It is still being kept up so that it works, though it is missing some of the other advantages of the KOFF connector.


Yes. Unfortunately, Kerio stopped "froze' it so that it won't work with any version of OutLook after Office 2007/SP3
  •  
Maerad

Messages: 158
Karma: 31
Send a private message to this user
The KOFF is really fine, even if it takes a bit more diskspace (if userprofiles are on a server/synced, just make a gpo to set the reg key to set the KOFF Cache to a local folder), it's really not bad. The user get's the possibility to have an "offline" cache (nice with desktops) and it's way faster then a online search/access. Also it takes some IO of the server itself. For a Terminalserver I recommend one, simple SSD and route all caches there. We use it with 20 Users permanently on our TS and it's simply fast. Even when searching a 30 GB Mailbox.

For the KOF EoL ... blame MS for it. They changed Outlook and it's closed source, Kerio has do build around that, that's why the KOFF, because you can't use the offline system of outlook without an exchange. Also Kerio works fine with their Webclient, because the server caches the files/searches etc. and can use them directly. Outlook KOF can't use it that way and the server has to do it without caches/nice features etc.

The big point for kerio is, that it runs on many different platforms, but it's also the downside, because you have to use programs and tools, that work everywhere. That's why the mails are stored as msg/eml in the store folder. Only the header/meta is in a DB.

Exchange dosn't have these limitations, because they can just use MS SQL and do everything in there. But exchange runs only on Windows, is hard to config / secure, way more expensive (most antivir cost more then kerio total) and needs a fuckload more of resources.
Also Outlook can use the native advantages of exchange, that kerio can't copy/do, because it's closed source.

I wasn't happy about the KOFF Offline Cache, but now, I really like it. And I never had any problems with it.
  •  
Michael Ruffin

Messages: 172
Karma: 4
Send a private message to this user
Maerad wrote on Wed, 19 August 2015 20:45
it's really not bad. The user get's the possibility to have an "offline" cache (nice with desktops) and it's way faster then a online search/access.


That I'm not sure about. I can do searches via the webmail interface and it's virtually instant. Some searches through Outlook take up to 10 seconds or sometimes even more.

Quote:
For the KOF EoL ... blame MS for it. They changed Outlook and it's closed source, Kerio has do build around that, that's why the KOFF, because you can't use the offline system of outlook without an exchange.


Not exactly sure what you're trying to say here, but I do understand that Kerio can't use the same offline cache system that is used with an Exchange server, as they have to use a plugin (KOFF) to access Connect with Outlook. The issue is, that it doesn't seem that the system they're using is very fast/efficient. At least that's what I'm concerned about.


Quote:
Also Kerio works fine with their Webclient, because the server caches the files/searches etc. and can use them directly. Outlook KOF can't use it that way and the server has to do it without caches/nice features etc.


Really? Is there some limitation on KOFF not being able to create a search index? The KOFF backend is always resident while Outlook is running, why can't it create a search index on each PC similar to Connect?

Quote:
The big point for kerio is, that it runs on many different platforms, but it's also the downside, because you have to use programs and tools, that work everywhere.


That's true for the server, but I would highly doubt that the programming required for PC/Mac Outlook is similar for KOFF.

  •  
Maerad

Messages: 158
Karma: 31
Send a private message to this user
Michael Ruffin wrote on Wed, 19 August 2015 14:08
Maerad wrote on Wed, 19 August 2015 20:45
it's really not bad. The user get's the possibility to have an "offline" cache (nice with desktops) and it's way faster then a online search/access.


That I'm not sure about. I can do searches via the webmail interface and it's virtually instant. Some searches through Outlook take up to 10 seconds or sometimes even more.


That's because the webmail interface uses the fulltext lucene search service. It's an opensource java application that indexes the mails into a db, so kerio can search the metadata this way. If oulook with KOC sends a request, I GUESS (not a developer) kerio has to actually search the files itself. KOFF is faster, because the files are cached locally and outlook should/can use the windows search for it to index (it's own local search DB). Should be like in PST files without exchange.


Quote:
Quote:
For the KOF EoL ... blame MS for it. They changed Outlook and it's closed source, Kerio has do build around that, that's why the KOFF, because you can't use the offline system of outlook without an exchange.


Not exactly sure what you're trying to say here, but I do understand that Kerio can't use the same offline cache system that is used with an Exchange server, as they have to use a plugin (KOFF) to access Connect with Outlook. The issue is, that it doesn't seem that the system they're using is very fast/efficient. At least that's what I'm concerned about.


KOFF is really fine. It can bite you in the ass if you have remote profiles for the users on your server, but in that case you can simply change the cache folder with group policies to a local one, outside the userfolder. What I tried to say is, that kerio can't use outlook exchange features, like offline browsing, cached search etc. pp. because the protocol and functions for it are closed source and not available for third parties. That's why they had to code / reverse engineer around it. I suspect the ppl wanted a offline function for outlook with kerio additional to the search performance issues you mentioned before. So the best way was so make KOFF, generate a local cache and use that for search, offline etc.

Also the Exchangeprotocol changed much since 2007, so maybe they don't have a way anymore, to interecept/use it with new things.


Quote:
Quote:
Also Kerio works fine with their Webclient, because the server caches the files/searches etc. and can use them directly. Outlook KOF can't use it that way and the server has to do it without caches/nice features etc.


Really? Is there some limitation on KOFF not being able to create a search index? The KOFF backend is always resident while Outlook is running, why can't it create a search index on each PC similar to Connect?


KOFF (Kerio Offline) can do that, KOC (MY MISTAKE! I wrote KOF instead of KOC...braindead me, sorry) connects directly and might not be able to use the kerio full index service or not like the webclient can. KOFF cache on our Terminalserver SSD is locally indexed and fast like it should be. Even faster then with exchange we had before.

Quote:
Quote:
The big point for kerio is, that it runs on many different platforms, but it's also the downside, because you have to use programs and tools, that work everywhere.


That's true for the server, but I would highly doubt that the programming required for PC/Mac Outlook is similar for KOFF.
[/quote]

Yeah, but the server tools are the impact. You can't use MS SQL with the package, what would be needed to speed up a "online" search with outlook and KOC. Also Kerio is made to use low resources, because it runs on small linux or mac server (mac mini anyone?) - those don't have a fast SAS raid with 30 GB RAM. Exchange with SBS 2010 used around 20-30 GB RAM on our Server before kerio. I cutted the SQL DB down to 10 GB and it was really slow after that.

Kerio needs like 1 GB (2,7 GB total on a Server 2012 Standard as domain server, file server and kerio). I don't think kerio put the KOC EoL for no reason and mostly it was because of technical limitations for a "online" connection. I for myself are quite happy the KOFF takes a bit steam of the server and lets the client handle it.

KOFF runs fine on a Celeron CPU 847 dual core, Windows 8.1, 4 GB RAM and a 2,5" 250 GB HDD (Shuttle DS47). No real difference to our Terminal Server or my own pc in terms of speed.

[Updated on: Wed, 19 August 2015 14:40]

  •  
Michael Ruffin

Messages: 172
Karma: 4
Send a private message to this user
Maerad wrote on Wed, 19 August 2015 22:40

That's because the webmail interface uses the fulltext lucene search service. It's an opensource java application that indexes the mails into a db, so kerio can search the metadata this way.


Right... in my experience with the Kerio Connect's that we support, the webmail searches are substantially faster (near instant) than the searches in KOFF. So my question is, if the Lucene search is faster, can this be implemented in the KOFF?


Quote:
That's why they had to code / reverse engineer around it.


I thought the API interface for connecting to Outlook was either open, or Kerio had a licence for it? I would highly doubt they reverse engineered it.

Quote:
KOFF cache on our Terminalserver SSD is locally indexed and fast like it should be. Even faster then with exchange we had before.


All of our clients have SSD drives in their local PC's with the KOFF cache stored locally... and it's still slow...and we still get complaints that it's slower than Exchange.


Quote:
Yeah, but the server tools are the impact. You can't use MS SQL with the package, what would be needed to speed up a "online" search with outlook and KOC.


I have no problem with the speed of any of our Kerio Connect servers, the speed issue is with the Kerio Outlook Connector. (If anything, the servers we manage hardly break a sweat and have processing power and disk speed to spare).

And the only issue that our clients have is basically the search function being slow. I'd ideally love Kerio to implement the search speed of the server onto a client's desktop. As I have mentioned previously, the search speed on webmail is near instant compared to the search speed on an SSD enabled PC running Outlook with the Outlook offline connector.



  •  
Maerad

Messages: 158
Karma: 31
Send a private message to this user
Michael Ruffin wrote on Wed, 19 August 2015 14:59
Maerad wrote on Wed, 19 August 2015 22:40

That's because the webmail interface uses the fulltext lucene search service. It's an opensource java application that indexes the mails into a db, so kerio can search the metadata this way.


Right... in my experience with the Kerio Connect's that we support, the webmail searches are substantially faster (near instant) than the searches in KOFF. So my question is, if the Lucene search is faster, can this be implemented in the KOFF?


Yeah, that would be interesting to know. But I guess, if they could do it, they would've already done so. Might be a business decision too, because supporting 2 different "clients" with mostly complete different technical backends might be too much for kerio. At least for now.

Quote:
Quote:
That's why they had to code / reverse engineer around it.


I thought the API interface for connecting to Outlook was either open, or Kerio had a licence for it? I would highly doubt they reverse engineered it.


The API or COM/MAPI is for clients like an ERP System to speak / interact with outlook. Or the addin system for additional functions. The communication between outlook and exchange is a proprietary protocol (not active sync). Or at least it was last time I checked.

Quote:
Quote:
KOFF cache on our Terminalserver SSD is locally indexed and fast like it should be. Even faster then with exchange we had before.


All of our clients have SSD drives in their local PC's with the KOFF cache stored locally... and it's still slow...and we still get complaints that it's slower than Exchange.


When we changed from exchange to kerio, I did some tests beforehand and there was no measurable difference between both. Fulltext search for all mail folders had the same search time with 1-2 seconds mostly as difference. With cache on my laptop 5200 turns/Min hdd.

Some ideas:
- Is the cache folder excluded from the antivirus? Also outlook.exe and koff.exe (or whatever the process was)
- What Client OS is used? AFAIK Outlook uses the Windows Search Index in PST Files and it should do so in Kerio. That means, Windows Search has to be installed and running.
- How is the load on the server? How much IO on the raid? Kerio is file based (and the search goes to the server first AFAIK for sync reasons) and doesn't like SATA Raids.
- Enough RAM free on the clients?
- Anything else on the clients that could speed down outlook? Anything on the Server?

Might be the users too. My experience is, that most ppl don't like changes and this can cloud their subjective feeling on some things. Just saying "its slower as exchange" is something I won't let count. Only hard facts are reliable. I searched on the same mail folder with the same amount the same things and counted the seconds with a stopwatch.

And like I said before, on the terminalserver with SSD I got even the response, that it's faster then before. Not by a wide margin, but a bit. Well, didn't measure that Smile

Quote:
Quote:
Yeah, but the server tools are the impact. You can't use MS SQL with the package, what would be needed to speed up a "online" search with outlook and KOC.


I have no problem with the speed of any of our Kerio Connect servers, the speed issue is with the Kerio Outlook Connector. (If anything, the servers we manage hardly break a sweat and have processing power and disk speed to spare).

And the only issue that our clients have is basically the search function being slow. I'd ideally love Kerio to implement the search speed of the server onto a client's desktop. As I have mentioned previously, the search speed on webmail is near instant compared to the search speed on an SSD enabled PC running Outlook with the Outlook offline connector.


If my above mentioned things don't make it faster, it might also be an outlook thing. If possible, try a real match between outlook + exchange and outlook + kerio KOFF and outlook + kerio KOC.

If available, try it with outlook 2015+ with active sync to kerio and measure this too.

You CAN'T compare the webclient of kerio with outlook. Even if outlook gets the search result faster, it's WAY slower then the webclient to actually build up the search result. Outlook has no multicore usage etc. like the server has. Like Access is way slower with selects then a mysql db.
The Webclient does locally access the server and just gives the output back to the user. Also it's way smaller/less functions/no useless stuff like outlook has. It's like comparing a Ferrari to a limousine. The Ferrari is fast, but has almost none comfort like the limo. I know, car examples are bad in the it world, but you should get what I mean with it Smile
  •  
derek_500

Messages: 40
Karma: 0
Send a private message to this user
I realize this is an old topic. I randomly found it while searching for a different Outlook problem we are having... sorry for dragging an old thread back if that's a problem!

We also used to have a lot of complaints about the Outlook Kerio Offline Connector and delays. Lots and lots of delays and calls about the 'spinning wheel' and Outlook 'Not Responding'. We use Outlook 2010 and reasonably decent desktop and laptop PCs with modern i5 and i7s, at least 4GB of RAM and 7200 RPM drives. The performance issues were not always directly related to the amount of email a user had, and little to do with the current performance on the server. Very heavy mail users were pretty much not able to use Outlook with KOFF. We started analyzing the disk activity and seek queue lengths and such and found that the KOFF was just crushing the hard drive when Outlook needed to do something. Since then (about 2 yrs ago) we've moved almost everyone to SSDs with incredible results in KOFF performance. Little to no noticeable lag times and no user complaints about Outlook's spinning wheels... Even for the heavy users with many GBs of email! A real win for everyone. I won't order a computer without an SSD today. Besides Outlook the overall performance benefits of SSDs save everybody time and aggravation!

Hopefully this info finds it's way into helpful hands. I'm not saying that it wouldn't be great for Kerio to solve the problem another way, but installing an SSD really made the difference. Try it if you haven't.
Previous Topic: BCC
Next Topic: DKIM with multiple domains
Goto Forum:
  


Disclaimer:
Kerio discussion forums are intended for open communication between forum members and may contain information and material posted by members which may be useful in learning about Kerio products. The discussion forums are not intended to provide technical support for any specific product. Any information implied or expressed in the discussion forums is that of the posting member. Kerio is in no way responsible for the information posted in the forums, or its accuracy. Kerio employees may participate in the discussions, but their postings do not represent an offical position of the company on any issues raised or discussed. Kerio reserves the right to monitor and maintain the forums to promote free and accurate exchange of information.

Current Time: Sun Aug 20 08:06:49 CEST 2017

Total time taken to generate the page: 0.00504 seconds
.:: Contact :: Home ::.
Powered by: FUDforum 3.0.4.