On Thu, Mar 15, 2007, Charles Marcus <[EMAIL PROTECTED]> said: >> Now we've got a customer who send and receive only really big mails, >> mostly 10-100mb per mail. They work with big images :-) Overall e-mails >> are about 140GB. >> >> I want to switch them from cyrus to dbmail, and wonder if somebody has a >> customer with lots of such e-mails (number and size). Would it be >> better, performancewise, to increase the messageblks, or do I not have >> to care about that? I'd better not change the default, because with >> every upgrade I'd have to change it. But I need to prevent a >> performance problem.
To the parent poster, I think you're going to have to benchmark this yourself, and please report your finding back to the list! Most email benchmarks are focused on high volumes of small email -- this is the typical use case, after all. We've so far only made sure that large email works, not necessarily works well. > We are in a similar situation (lots of attachments - some big) - but I > cannot see taking the time/effort to switch to dbmail until it supports > single-instance storage of at least attachments. This would most likely > dramatically impact your storage requirements, as it would ours, since > I'll wager that at least some, if not a lot, of the attachments your > users work with are duplicates. Having 25 copies of an email with 25 > copies of a 25MB attachment is just plain insanity to me - especially > when it doesn't have to be that way. > > Having a database as a backend for an email storage system is an ideal > environment to be able to handle this, so I was very disappointed when I > found out that dbmail doesn't support it (actually I was thinking that > would be a/the PRIMARY reason to use a database to store email). It's one of many good reasons. For the 2.0 series, our goal was getting the code really stable, and for 2.2 it was making IMAP faster and improving the whole system all around. For 2.4 we are looking a lot of interesting ideas, but it's likely that we'll want to again keep the database largely unchanged and further improve the code. Breaking out attachments will require not just schema changes but a full migration, with software required to retrieve each message, reparse it, and reinsert it according to the new schema. > Anyway, I'm just waiting (impatiently) until dbmail supports this before > we switch. I wish I could convince the boss to make this a paid feature > request, but he doesn't 'get' computer stuff and doesn't understand how > much it would benefit us. Paul and I write the code that interests us and what we can sell support contracts for. This feature would be a lot of work for hack-value equal or less than many of the other features we've got on the drawing board. If there were a strong business case, that would definitely change the equation! Aaron _______________________________________________ DBmail mailing list [email protected] https://mailman.fastxs.nl/mailman/listinfo/dbmail
