Goodbye for now, kmail

Sat May 6 00:09:26 BST 2017

On Friday, May 5, 2017 4:45:08 PM CEST Martin Steigerwald wrote:
> Pablo Sanchez - 05.05.17, 09:06:
> > [ Comments below, in-line ]
> > 
> > On Fri, 05 May 2017 17:57:39 +0530, Vishnu V. Krishnan wrote:
> > >> You can use Akonadi with PostgreSQL instead of MariaDB. Not sure
> > >> whether
> > >> that helps w.r.t. systemd. Use the search engine of your choice for
> > >> instructions.
> > > 
> > > Thanks for pointing it out. Upon looking into it, I don't think I'll be
> > > able to get rid of MariaDB, because in all the distros I use (Arch-based
> > > stuff), Akonadi is built with MariaDB as a hard-dep. Looks like I'll
> > > have
> > > to build it myself to change this, or use a distro like Gentoo.
> > 
> > I don't believe the DBMS engine is the problem.  IIRC, we'd be sending
> > the same extraordinary number of SQL calls.
> 
> Zimbra is an example based on MySQL/MariaDB + Lucene that works really nice
> with million of mails – and even more, I am not sure whether thats still the
> case, but at least it was the backend for Yahoo Mail and that tells
> something. So no, the DBMS is not the issue … but I think it needs to be
> automatically configured and managed as I would require no ordinary user to
> be a database admin as well…
> 
> I currently see the following issues:
> 
> - Akonadi does needless work – like to frequent folder and too expensive
> synchronisations (on IMAP after every few mails you delete). It requests all
> DB entries for the collection it synchronizes to compare what is stored in
> backend storage like IMAP or local Maildir. 

This is only true for Maildir and mixedmaildir resources. There are certainly 
other more efficient ways how to do this nowadays, someone just needs to look 
into it. As always, patches are welcomed.

> For local maildir I would like
> to disable automatic folder synchronization *completely* cause I know that
> Akonadi Maildir is the only user of it, yet it checks frequently whether
> the million of mail files is still there.

Just turn off Automatic Synchronization for the folder. If the sync is still 
triggered, then it's triggered due to some external factor, and it needs to be 
debugged what triggers it.

> - Akonadi does more needless work: When you moving a folder from one parent
> folder to another parent folder within a local Maildir resource it first
> creates the new folder, then copies all mails, then deletes it from the
> source folder, essentially moving them and then deletes the source folder…
> instead of just *renaming* the folder.

Not true. The folder is renamed (see MaildirResource::collectionMoved() and 
MailDir::moveTo()).

> - Akonadi does more needless work: I reported several other bug reports.

Akonadi does a lot of work. When you implement a very generic service like 
Akonadi, it's going to perform better in some cases and worse in other ones. 
You can't implement a generic service that performs 100% in all cases.

> - Akonadi has no notion of multitasking and background tasks – a folder
> synchronisation blocks interactive user requests by kmail.

Addressed in my other email.

> - Akonadi does not auto-tune MySQL performance settings like InnoDB buffer
> pool size with is ridiculously low after anything than a few mails. A too
> low InnoDB buffer pool size leads to additional file I/O accesses.

innodb_buffer_pool_size has been doubled in 17.04 release (to 128MB).

> Thing is: All of these issues are known since years. And while Dan, Milan
> and others did impressive performance optimizations these basic issues are
> all still unfixed.

Patches are welcomed.

> And as such, while KMail and Akonadi works well enough for me after raising
> InnoDB buffer pool size to 1 GiB, and believe me I can easily notice when on
> an Akonadi upgrade it gets downgraded to 80 MiB again…, I can fully
> understand the massive frustration with it. Usually I have retrieving
> folder contents or mail notifications only for a few seconeds, but I am
> still seeing this. And this is on Dual SSD BTRFS RAID 1 with surely fast
> enough Sandybridge ThinkPad.
> 
> 
> So while I believe that creating a solution that works and uses an DBMS is
> possible… for some reason be it lack of developer time and/or design issues
> within Akonadi, Akonadi still is not that solution. And thats after more
> than 5 years of introducing it. So I perfectly can understand the
> frustration and I certainly also can understand the arguments to ditch
> Akonadi completely or replace it by something else like Sink. However Sink
> probably did not prove itself in the scenarios KDEPIM would need it for.

Sink has some very good concepts that I like and we will be gradually evolving 
Akonadi towards those concepts. But I don't want to walk down the route of 
"let's throw everything away and start from scratch" though.

Dan

> 
> Ciao,

-- 
Daniel Vrátil
www.dvratil.cz | dvratil at kde.org
IRC: dvratil on Freenode (#kde, #kontact, #akonadi, #fedora-kde)

GPG Key: 0x4D69557AECB13683
Fingerprint: 0ABD FA55 A4E6 BEA9 9A83 EA97 4D69 557A ECB1 3683
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdepim-users/attachments/20170506/84b9cec1/attachment.sig>