[Kde-pim] Akonadi mail performance outlook

Fri May 2 09:19:15 BST 2014

Am Donnerstag, 1. Mai 2014, 21:50:40 schrieb GEO:
> Hi,

Hi GEO,

> I am using Akonadi for my mail setup now more intensively than every before
> and have an mail account with over 10 000 mails atm. This is enough to see
> some performance issues associated with Akonadi.

What version are you using? If still 1.12.1 or older, I suggest trying out 
Akonadi git. I am using Akonadi with an enormous IMAP account on an Exchange 
2013 cluster… and despite as to what I learned in trying out Trojita as well 
about the deficiencies of the Exchange IMAP interface, it turned out to work 
quite well. Well I got some IMAP connection aborts two days ago, but that I 
bet is likely an issue with the IMAP server itself.

So an interesting question is also: Which IMAP server do you use? I 
recommended Dovecot as to my knowledge it is one of the fastest IMAP servers 
you can install.

> Here are my top 3 (in the following folder sync means when you have just
> created your account and you click a folder):
> 
> 1.) When configuring an imap account (gmail in my case) and you click a
> folder in kmail, the sync will begin. (No special settings, just created
> the account with the account wizard). If you click another folder now,
> nothing happens, it will wait till the initial folder is completely synced.
> This is not exactly asynchronous and should be addressed.

I can confirm that for sync operations in a huge maildir resource which is 
filled by POP3 agent. A sync operation blocks out KMail for minutes. Which 
doesn´t match one of the design goals for Akonadi.

I wanted to look into this further and I actually had a look at the source. 
All I could find there where some calls about synchronize collection tree with 
a comment that this may not be needed here, but that this wouldn´t matter. As 
I didn´t yet follow read up / understood what this call does and had different 
things to do… I didn´t get follow up on this.

> 2.) Syncing a folder begins with the oldest messages. If the account is big,
> it takes some time till you reach the latest message. In reality, you might
> be more interested in you latest mails at first, so doing that in reverse
> order would allow you to make use of kmail instantly, without waiting for
> the sync being complete.

Great suggestion. I recommend to file a wishlist bug about that with 
bugs.kde.org

> 3.) During the folder sync, it is nearly impossible to click a message in
> the folder. You will have to wait extremely long. This should not be the
> case. Fetching a message content should be completely independent from
> syncing the folder and should only be limited by physical things like
> connection speed, disk i/o, cpu load, ram etc.

I found this to be the case as well. Yet… with Akonadi git I usually have 
KMail "only" blocked on changing folders during a synchronization run. It does 
not seem to wait for a new message for more than a view seconds. With Akonadi 
git the performance generally seems to be better.

> 4.)  Please implement parallelism in Session and Resources, to avoid the
> authentication dialog blocking all Akonadi ressources, if one server does
> not respond.

Also a nice idea. Please also file a wish list bug about it.

My oppinion on this is:

If KMail GUI blocks while KMail is waiting for Akonadi, its a bug. As it does 
not match the stated design goal of Akonadi:

Concurrent access allows background activity independent of UI client

    Syncing mail, calendar, addressbooks to remote servers
    Syncing with mobile devices
    Permits semantic desktop infrastructure to access PIM data
    Archiving
    Indexing
    Out-of-process search

http://community.kde.org/KDE_PIM/Akonadi

> The idea behind this is, to be able to configure your account and start
> being productive right away, without having to wait, till akonadi has
> cached everything. The only component that works like this atm, is sending
> mails, that works right away, but for everything else you would want to do
> (read mail and respond) etc. you have to wait.
> I have not tried mail filters yet during initial sync, but I think they will
> work in parallel.

Sending and mail filtering is handled by different agents.

I think KMail is only blocked if it accesses the Akonadi resource that is 
actually busy. I proved this here actually with maildir resource. If I kill 
the 100% CPU busy akonadi_maildir_resource process KMail *immediately* 
responds to the last action. And as Akonadi restarts the resource again, it is 
blocked afterwards again.

IMHO is with a severe deviation from the original design.

> I know that implementing this might not be trivial, it would be a long term
> wish though. It has nothing to do with criticism, in fact I am a fan of
> akonadi and I respect the enormous efforts of the devs.
> 
> Once Akonadi is up and running, everything is pretty fast in my experience,
> not even trojita is faster. But for initial setup it is still lacking in
> terms of  the time you have to wait to start working.
> I know, some are of the opinion that you do not recreate your mail account
> every day, but I think, especially for big account, addressing the first 3
> issues would really be cool.
>
> KDE PIM home page at http://pim.kde.org/

I think fixing the GUI blocking is important. Actually I used that kill maildir 
resource work-around quite some times already, cause when I want to look up a 
mail in a different folder than KMail displays currently I want to switch to 
that different folder and I want to see that mail *now*. With "now" meaning it 
appears within at most 10-15 seconds in extreme cases, but better within not 
more than 5 seconds. Not minutes.

I think it happens more for huge accounts. Still as to my last research I am 
pretty sure in my maildir case that is it neither the MySQL database nor the 
Dual SSD BTRFS RAID 1 storage speed on this Sandybridge laptop being the 
bottleneck. I am pretty sure there is a design issue / bug in Akonadi.

Ciao,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/