Paul J Stevens schrieb: > Daniel Urstöger wrote: > >> yes, I will have to update my script accordingly, it just gives me >> quite an advantage accessing the data directly via SQL and not havening >> IMAP as intermediate layer, performance wise. > > Misconception. IMAP performance is just fine. But many imap clients do not > leverage it properly. But the choice is yours of course. > > And: there is still plenty room for improving dbmail's imap performance, I > know.
okay, well I can only reflect what I have been testing so far and access via IMAP to the database has given me a longer response time / load time compared to fiddle around directly within SQL. That of course might be a problem with PHP IMAP libraries too. >>> That's correct. Forwarded is not a supported flag (yet). >> Okay, so how does a mail client recognize this? via an IMAP command to? > > yep: the PERMANENTFLAGS line of the SELECT response. > okay, but 2.3 will change that? so at least viewing the >>> For now: use IMAP's "FETCH n (BODYSTRUCTURE)" >> hmm, (without looking in the source code of dbmail) what does happen >> here? The whole message is opened by the IMAP daemon, the structure is >> extracted from the message and then returned? if so, I could do that in >> a PHP subroutine too and maybe cut the system resources a bit ... > > Yeah, right :-) but you need a very good mime parsing library. 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. So after fetching the emails content the rest of the workload is on the other server, so I can split the load a bit. The problem here is: currently the system is not loaded at all, but soon its gonna have about 20 000 mailboxes and about that many users connecting to it. So everything that could split load, reduce time etc. is helpful, even if it costs me a day worktime to get it coded / working :) >> 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)]) > > 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. 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. okay, thanks for your tipps, it seems like that is unecessary after all :) _______________________________________________ DBmail mailing list [email protected] https://mailman.fastxs.nl/mailman/listinfo/dbmail
