Paul J Stevens пишет:
Bokhan Artem wrote:
Paul J Stevens пишет:
Bokhan Artem wrote:
Paul, what for dbmail executes this query with imap "select Inbox"?
It retrieves the meta data for all messages in the mailbox involved.
I suspect that metadata is cached by imapd and used in further imap
queries... That is probably good for small mailboxes, but definitely
kills system with real-life mailboxes. May be caching of meta of last N
messages would be better...
Currently the cache indeed is build when a client opens the mailbox.
Several imap clients will issue something like 'x uid fetch 1:* (flags)'
to update their client-cache right after opening a mailbox. So rather
than wait for the 'fetch 1:*' command, the meta-data is retrieved as
soon as possible.
Also, some of this caching has to be done anyway, because the
SELECT/EXAMINE commands will return data that needs to be calculated and
tracked as session-local data. The state of the mailbox in the
data-store is - as much as possible - only used to synchronize
concurrently connected clients. We need to maintain a comprehensive
internal view of the mailbox, exactly to avoid doing unnecessary queries
later on.
I seriously doubt this will 'kill' your system, even for very large
mailboxes. I use this routinely on mailboxes > 5000 messages and it only
causes a minor delay when I first select the mailbox.
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.
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.
All data for "select", if possible, should be calculated while
messages/meta inserted/modified. Others (if there are) should be
calculated by database.
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.
_______________________________________________
Dbmail-dev mailing list
[email protected]
http://twister.fastxs.net/mailman/listinfo/dbmail-dev
