[Kolab-devel] Kontact Performance, once again...

[ITSEF Admin]

Chris, Martin, first of all thanks for replying - you did a lot to keep me 
sane today... ;-)

On Wednesday 11 October 2006 08:57, Martin Konold wrote:
> Am Dienstag, 10. Oktober 2006 10:43 schrieb ITSEF Admin:

> > I'm not 100% sure whether this should go to the users list
>
> I any probably other unsubscribed from the users list due to some
> semantics...

Uhm... Parse error??


> > I am *still* struggling with the performance of Kontact.
>
> Which version of Kontact are you using?

<quote>proko2 after 2.1.4, currently revision 591884</quote> ;-)


> In short: Kontact dIMAP implementation sucks. I hope that it gets fixed
> soon with KDE 4. The current implementation is based on "synching" which is
> totall wrong and leads to many accesses to the filesystem. The performance
> is then latency bound. Latency is very bad if Linux and NFS.

Right, at least I'm not imagining things here. That doesn't help with the 
issue as such, but as I said, having confirmation at least keeps me sane...


> Is using a local storage(*) an option for you?

I have to look into this again. Up until now, that's precisely what we were 
using. There are, however, several issues with this approach:
- To have the dimap directory locally, every user account needs to have a 
suitable symlink in ~/.kde/share/apps/kmail to a local directory. This is not 
something I particularly like.
- I'm not 100% certain what happens when users switch machines (after all, 
that's one of the reasons we have a file server...) - in those cases, the 
dimap cache is not there. I *think* KMail deals reasonably well with this, 
but there is some vague uncertainty left. If somebody can calm my nerves in 
this regard, please do... :-}
- During my first round of experiments (before the server upgrade), having 
dimap local was not enough - KMail *also* starts a flurry of activity on some 
files in ~/.kde/share/config (kmailrc, kdeglobals, several lockfiles), thus 
aggravating the problem. Having ~/.kde/share/config local, however, is a 
minor desaster - especially, if people want to be able to switch machines. 
All sorts of script and symlink trickery is needed to make certain that an 
up-to-date version of all config files is always present on any machine the 
user cares to log in on. This has proved fragile over the past months, so I'm 
not happy at all about this. I'll probably re-run some experiments with only 
dimap local and config on the NFS share, hoping that the fileserver upgrade 
was enough to make at least *this* approach bearable.


Another question: I did not find any issue specifically addressing this 
problem - any sense in me creating one?

Cheerio,

Thomas