On Mon, Oct 1, 2007, Daniel Urst�ger <[EMAIL PROTECTED]> said: > 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 more] >>>> 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. Each ajax query is often still its own HTTP request, so you're just hiding some of the latency rather than totally resolving it. That's not a bad thing, but the first line of defense should be improved architecture :-) When you scale out beyond a single web server, you'll want to keep this intermediate information in some shared storage. I recommend using memcache for this. If you only keep the information in your app (in PHP? using native sessions? yuck!) then you'll have issues with server affinity between page loads. Aaron _______________________________________________ DBmail mailing list [email protected] https://mailman.fastxs.nl/mailman/listinfo/dbmail
