On Mon, 2007-10-01 at 16:58 +0200, Daniel Urstöger wrote: > Paul J Stevens schrieb: > > Daniel Urstöger wrote:
[snip] > PHP offers a native module, I would have to test though if that is > faster then working with IMAP. Though there is some other consideration: > I have 2 Servers in place, one handles dbmail, the other one is > pratically the webserver for PHP etc. The PHP native IMAP module is hard to use efficiently, see below. > >> well Paul, here we are: basically my script does two things: first it > >> generates a list of all messages in the inbox and shows one of them > >> accordingly to users settings ( just like the overview in Outlook / > >> Thunderbird). So, the overview list is basically the dbmail_messages > >> table with a few joins ( like subject, etc.) so far and showing the > >> selected messages it has to deal with mime already. > > > > A typical IMAP call to retrieve such information would be > > > > x UID FETCH 1:* (UID RFC822.SIZE FLAGS BODY.PEEK[HEADER.FIELDS (From To Cc > > Subject Date Content-Type)]) Are you doing this on every page load? If so, you will never have good performance because you've turned every O(1) page load of a single message into an O(n) retrieval of the entire mailbox. > > which indeed maps to just the kind of joining query you currently use. The > > content-type header will generally tell you whether or not you need to > > display > > an attachment icon. Retrieving the full bodystructure info is most likely > > only > > needed to generate the message view-pane, not for the list pane. This is the crux of the problem of using the c-client API that underlies the native PHP IMAP module -- it's really oriented towards a stateful client such as Pine, and as such, retrieving all data in one call is a useful optimization. For web this can be a significant problem. > okay, so if Content-Type is multipart you would show the attachment > symbol for that email? Did I get that right? > > >> BUT if for the overview I have to open EVERY email completly and look > >> around for mime stuff that will significantly drop performance. Atm the > >> script is able to handle 2000 emails in the inbox within 2 seconds of > >> page load time and I like that to keep this that way. If not possible I > >> would have to cache information but mainly I have performance in mind. > > > > Really, if you write a webmail client that needs to retrieve the body > > structure > > of 2000 message at once, go back to the drawing board. Email clients that > > dont > > want to build a big offline cache don't need that much info. Yep. 1000 messages per second is terrible. What do you do with someone who has 10,000 messages? 10 seconds per page view? Aaron _______________________________________________ DBmail mailing list [email protected] https://mailman.fastxs.nl/mailman/listinfo/dbmail
