Bokhan Artem wrote:
That probably means that during that seconds your cpu is 100% busy. I
have about 200k accounts per server, and that behavior is very risky.
Do not forget about imap webmail clients, which log in every time they
need to do something. Imapproxy is workaround as it caches established
connections and "select", but anyway.
But there is also database caching going on in the server, so repeated
queries for the same data tend to be much faster than the first one.
And that's using a
very old 1.6GHz dual-xeon with 512mb ram.
So what you see is all building on my main use-case: thunderbird and
outlook accessing small or medium sized mailboxes < 10k messages. I'm
sure that using large or very large mailboxes combined with different
imap behaviour patterns in the client are better served by different
caching behaviour.
So as always, feel free to offer ideas how this might be improved.
I would suggest that some kind of buffering is needed here. I mean that
operations "select ... where uid=1" and "select ... where uid>1 and
uid<100" will probably cost the same for the system.
Not really. Doing 100 repeated queries for 'where uid=n' is much more
expensive than doing a single 'where uid>n1 and uid <n2'.
All data for "select", if possible, should be calculated while
messages/meta inserted/modified. Others (if there are) should be
calculated by database.
Of course.
Only small prefetch with select, so time spent on db queries would be
negligibly small.
Metadata for "* uid fetch" should be queried from database by blocks
(50,100,500 rows, don't know) and then placed to cache.
Ok, we're already doing something similar for queries like this one that
is typical for outlook office:
X FETCH 1:* (BODY.PEEK[HEADER.FIELDS (References X-Ref X-Priority
X-MSMail-Priority X-MSOESRec Newsgroups)] ENVELOPE RFC822.SIZE UID FLAGS
INTERNALDATE)
This basically needs a join on several tables for all messages, messages
headers, envelopes etc in the mailbox involved. Rather than doing a
single select, the whole range of message ids is sliced up in blocks,
and the database is queried repeatedly for data just for the messages in
the block at hand. The main reason was that otherwise it took too long
to load large mailboxes.
I'll have to take a good look at this because I really don't want to
mess up IMAP compliance this close to 2.4.0's release.
--
________________________________________________________________
Paul Stevens paul at nfg.nl
NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31
The Netherlands________________________________http://www.nfg.nl
_______________________________________________
Dbmail-dev mailing list
[email protected]
http://twister.fastxs.net/mailman/listinfo/dbmail-dev
