Aaron Stone schrieb: > 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.
seems to be the case, yes. >>>> 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. not really, the page is ajax based, so many things do happen without any page reload and additional to that, everything retrieved from the database gets cached within my program, so for some time even page refreshes do not cause new sql querries. >>> 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. yes, I heard some people having good results by using an imap proxy, but I really dislike adding another layer that might cause problems. If necessary though, I prolly will have to do that anyhow. >> 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? no, at some point I will have to split the view and make people browse forward / backwards. Have not yet decided abotu the cap. And time included page load of course, I would have to check how much time it takes for sql query to run through and PHP to calc the things ... Thanks for your help and input! > Aaron > > _______________________________________________ > DBmail mailing list > [email protected] > https://mailman.fastxs.nl/mailman/listinfo/dbmail _______________________________________________ DBmail mailing list [email protected] https://mailman.fastxs.nl/mailman/listinfo/dbmail
