Michael Monnerie wrote: > I can't really benchmark this, it's a customers server, no time for > playing around there. Cyrus works, so I won't touch it. I would have > thought that big messages are no problem, as the DB should be much > faster than the network anyway. Even when a message has 100MB, that > would only be 50x512KB to store in messageblks. And to find and > retrieve 50 blocks can't be that hard, especially when there's an > index.
It's not the retrieval that'll cause problems. What I was referring to was when clients do a lot of IMAP SEARCH-ing on such large messages where they search the actual body, and not just meta-data such as subject or sender. My first confrontation with dbmail-2.0's imap limitations was when I deployed 2.0 with a client who receives a *lot* of 100MB messages, and where *all* clients (10+) did a lot of full body searches on them. Performance on 2.0 was simply non existent in that use case. That's pretty much what prompted me to dig into dbmail's imap code. But I agree: storing attachments in separate messageblks should be done in a backward compatible way. No conversion of already stored messages should be required. -- ________________________________________________________________ Paul Stevens paul at nfg.nl NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 The Netherlands________________________________http://www.nfg.nl _______________________________________________ DBmail mailing list [email protected] https://mailman.fastxs.nl/mailman/listinfo/dbmail
