[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-pim
Subject:    Re: [Kde-pim] Akonadi mail performance outlook
From:       Christian Mollekopf <chrigi_1 () fastmail ! fm>
Date:       2014-05-02 16:48:59
Message-ID: 2999762.jdoEFC9d6O () t420s ! chrigi
[Download RAW message or body]

On Friday 02 May 2014 11.28:22 Daniel Vr=E1til wrote:
> On Thursday 01 of May 2014 21:50:40 GEO wrote:
> > Hi,
> > =

> > 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.
> > Here are my top 3 (in the following folder sync means when you have just
> =

> > created your account and you click a folder):
> Hi,
> =

> > 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.
> =

> This is a known problem with session blocking. Not sure how to solve this
> yet, sorry.
> =

> > 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.
> =

> That's very hard, because in IMAP, you can only query sets of items in
> ascending order (1 being the oldest message), so we can only query 1:* (f=
rom
> first to last), not *:1.
> =


That's actually solvable. I already implemented batch processing and UID ba=
sed =

fetching. This will allow us to implement reverse fetched batches, and =

eventually also limiting the number of mails that are synced offline.
We can't do reverse fetching just yet, because a couple of checks rely on t=
he =

message count, which doesn't take into account that messages could also be =

missing on the lower end.

> However you only do the complete sync once, after that it's only
> incremental, i.e. IMAP resource only requests changes since last check (n=
ot
> on Gmail, that has to check all emails in the folder, because their suppo=
rt
> for this feature is broken, but I'm working on it).
> =

> > 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.
> =

> It cannot be independent, because in the background it shares the same
> database, where database locking and long transactions (known problem,
> again) lead to retrieval operations taking long time.
> =

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

> That is a hard problem, but something we indeed want to have at some poin=
t.
> =


Perhaps we can improve i.e. kmails usecase by using cache-only for the ETM =
+ a =

separate session when on-demand loading a mail for the viewer/editor?

Not sure what else would be blocking, or why we would need it to not be cac=
he-
only.

Cheers,
Christian
_______________________________________________
KDE PIM mailing list kde-pim@kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/
[prev in list] [next in list] [prev in thread] [next in thread]