Proko2 client performance?

[T. Ribbrock]

On Wed, Mar 29, 2006 at 01:19:13PM +0200, Bernhard Reiter wrote:
> Am Dienstag, 7. März 2006 12:19 schrieb T. Ribbrock:
> > See, that was the major problem: Most of the time, you *can't* continue
> > working, as the rest of the program got so slow that even typing some
> > characters takes seconds instead of instants - on a fast machine.
> > Otherwise, this would be a non-issue. Apparently, this does not happen for
> > you?
> 
> No. I guess something else is wrong.
> BTW: I have created a wiki page for helping to diagnose problems
> on the KDE Kolab client at:
> 
> http://wiki.kolab.org/index.php/KDE_Kolab_Client_-_Tips_&_Tricks

Very nice, thanks!

As I'v mentioned in another mail, I'm a step further: The big slowdown is
our NFS fileserver setup, which cannot handle the load. However, I spent
some time trying to analyse what's going on and found the following:

- Our NFS setup is simple, but was sufficient for 12 users with their home
  directory on the server.
- The server went to its knees when all those users got kontact proko2.0.6
  and started using it.
- Upon investigating, I could identify the following causes:
  * kmail has to walk through the entire mailfolder tree to update (or
    at least test for changes in) the local copy of the tree. This is a
    property of the DIMAP setup Kolab has chosen and as long as it is not
    possible to exclude some folders from this, there is not much to be
    done about this.
  * an strace run of kontact revealed that kmail accesses kmailrc at least
    once per folder. In addition, it sets up (and deletes!) plenty of
    lockfiles for kmailrc. This seemingly causes a bunch of "small stuff"
    traffic on the NFS share. In larger accounts, this is part of the
    slowdown problem.
  * The same strace run showed that kmail also does quite a few accesses
    of kdeglobals - again with plenty of lockfile activity - another
    contributor.

As we cannot update the file server right away, we ended up storing a lot
of stuff locally. To get kontact to act swiftly, I had to move
~/.kde/share/apps/kmail/dimap and ~/.kde/share/apps/config to a local
drive - only then would the client be usable. I'm still surprised that
simply waiting for the NFS I/O caused the whole thing to get sooooo
sluggish - I'd have expected that the sync takes more time, yes, but not
that you cannot work with the client anymore because the whole GUI becomes
slow as molasses (on a fast machine, mind you).

Cheerio,

Thomas