Aaron Stone wrote:
> I suspect the SM function in question is this one:
>
> /**
> * Retrieves a list with headers, flags, size or
> * internaldate from the imap server
> *
> [snip]
> function sqimap_get_small_header_list($imap_stream, $msg_list,
> $aHeaderFields = array('Date', 'To', 'Cc', 'From',
> 'Subject', 'X-Priority', 'Content-Type'),
> $aFetchItems = array('FLAGS', 'RFC822.SIZE', 'INTERNALDATE')) {
> [snip]
> }
This is not the *main* bottleneck. None of the fields enumerated here
trigger message retrieval. That said, retrieval of these values is at
this moment still not quite as fast as it should be. The problem is also
described in bug http://www.dbmail.org/mantis/view.php?id=139. In short:
dbmail's fetch command retrieves the required information message by
message, instead of gathering information for all required messages with
a minimum number of queries. But I'm already working on a rewrite of the
fetch code that will address this problem. Won't be ready before 2.2 though.
At this point the _only_ things that trigger full message retrieval and
parsing are:
envelope
bodystructure
body[]<> and friends (rfc822.xxx)
search text
The first two can be optimized fairly easily, with only minimal changes
to the delivery chain and the addition of two new cache tables.
The last _can_ be optimized but will require more extensive changes and
a new daemon. I've outlined this in a wiki:
http://www.dbmail.org/dokuwiki/doku.php?id=bodysearch
The body[]<> (partial) message retrieval will always require message
retrieval by nature.
--
________________________________________________________________
Paul Stevens paul at nfg.nl
NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31
The Netherlands________________________________http://www.nfg.nl
