martin.konold at erfrakon.de
Thu Jul 20 04:07:57 EDT 2006
Am Mittwoch, 19. Juli 2006 19:47 schrieb Ken Murchison:
> I like the design of the patch, but I'm not sure that using the mailbox
> sort order is correct for ALL databases (seen state, annotations).
> Perhaps the comparator function should be selectable by a flag. I need
> to think about this a little bit.
> but I'm not sure that using the mailbox sort order is correct for ALL
> databases (seen state, annotations).
I am using this patch with Kolab successfully since some limited time. Kolab
makes heavy use of annotations etc.
I quickly verified mboxlist_db quota_db seenstate_db and subscription_db.
They all look fine and working to me.
> Perhaps the comparator function should be selectable by a flag.
This feature sould then be analogous to the way how bdb implements a user
definable comparator function. Though I consider it currently as being
slighly overenginered. (*)
(*) If cyrus_skiplist is supposed to become a generic db backend imho a
selectable or better user changeable (via a callback) comparator function is
a must but for within Cyrus Imapd I have the impression that a single
comparator is fine according to the kiss principle.
> > BTW: What is the future of the bdb backend?
> Its still the most efficient backend for random access databases like
> deliver.db and tls_sessions.db
Thanks for hinting at this issue. Do you think it is feasable to improve the
random access performance(*) of cyrus_skiplist? Maybe using suitable
I have the impression that from the point of view of the Cyrus imap server it
is important that the deliver.db performes with regards to throughput and
resource requirements not latency. I am concluding this because I assume that
the deliver.db is mainly used for non interactive tasks.
Is this correct?
(*) IMHO performance in this context means several issues:
- latency time (how long does it take to finish a single task)
- throughput (how many potentially concurrent operations can be handled
in a fixed time frame)
- scalablity with the number of entries
- scalability with the number of concurrent accesses/sessions
- cpu usage
- memory usage
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker
More information about the Cyrus-devel