On Fri, 2012-06-22 at 01:54 -0700, email builder wrote: > It's a little unknown for now, which is why I left it open. For starters, at > least hundreds of concurrent IMAP users (growing quickly), tens of > thousands of new messages per day. Folder sizes will start small but > we expect them to grow quite quickly without much expunging.
Probably not a level where I would worry too much about critical bottlenecks emerging any time soon with any IMAP server and single active decent x86 server, but the best time to avoid future bottle necks is the design time I guess. > Most users on webmail, some using IMAP desktop clients. I've heard > at least anecdotal evidence suggesting the same thing. I hate to be > saying stuff like that on this list. :( Well, Courier IMAP has other advantages. It's well tested and stable, not just in terms of crashes but in terms of the software structure. Revolutionary ideas that lead to the rewriting of large parts of the server software from time to time (as are still happening in Dovecot as far as I can tell) are not everyone's cup of tea, especially if you adapt parts of Courier IMAP to add some extra functionality for your own purposes. On the other hand, maybe Dovecot already has that functionality or provides plug-in interfaces to help you achieve the same ends. Also, again as far as I can tell, Dovecot is a far more complex beast than Courier IMAP, no doubt due to its additional features, with all the good and bad consequences this entails (cf. the bind vs djdns debate. Well not really ;). > Haven't decided yet, but leaning toward some sort of NFS-ish solution. > Would love to hear more advice on this. My understanding is if we > used Dovecot's dbox where filenames don't change as they do in > maildir++ then the biggest problem with IMAP over NFS which is lots > of small writes becomes not such a big problem. Is this correct? We haven't tried this, but having chatted with a colleague about this who recently attended a Dovecot training course, dbox seems to be mainly about addressing deficiencies with the underlying file systems that are bad at dealing with lots of small files, not so much about issues related to using NFS itself. Put bluntly, if you are not using a Linux+ext3-NFS-Backend and not try to backup your emails using rsync, he's not convinced that mdbox is worth the much more complicated file structure. The latter can be become important if you want non-dovecot first level admins to be able to do maintenance ops on user folders. > Problem there is that we have lots of maildrop scripts that would be > hard/impossible to migrate to sieve - we'd have to consider continuing > to use maildrop but make it call Dovecot LDA for ultimate delivery or > figure out how to convert maildrop scripts to shell scripts that sieve > can pipe to. I can imagine that this would be a big issue, especially if your users would be able to write their own maildrop filters. You'd be lucky there if you'd abstracted the generation of these filters via some immediate DB layer or something. Then you could easily replace the db-format -> maildrop generators bei db-format -> sieve generators. > Budget may dictate the latter. Does something like GFS make > sense or add to the layers that sap latency and performance? We've never tried it, but the fact that GFS is a block device technology and that you will be stuck with Linux file systems (btrfs isn't really stable yet and ZFS is not really available as a kernel level file system) would be a big downside for me. You still need a decent iSCSI SAN presumably for GFS to work well. > > Linux' NFS client implementation used to suck quite badly > > several years ago at least, FreeBSD was better and Solaris Sparc > > (on Niagara) was better still. > > I ran into big problems trying to use Courier over NFS a few years > so I agree! But it's improved recently enough to give it a try? Not sure. At the prices that Oracle has been charging since their takeover of Sun for their T3/T4 machines running Solaris, you can afford of a lot of extra Linux boxen to make up for any NFS gains that Solaris still might offer. > Thus the idea of calling Dovecot LDA from inside maildrop. Yuck, > but it's CPU cycles at delivery time versus better IMAP performance, > so maybe it's alright. Sure, in my experience, the IO/CPU resources of actually delivering mail are far less relevant than the IMAP part. Especially considering that the IMAP part is more or less an interactive thing, whereas your users are unlikely to make a big fuss if your delivery infrastructure is occasionally a little slow. > Gotcha. Was considering XFS too, but I don't think it allows snapshots. > With GFS...? You're right, this will require difficult thought Btrfs will probably be the ideal Linux filesystem for this once you trust it enough to handle your email. But if you are not limited to Linux or you trust the user space implementations, there is always the wonderful ZFS. <Insert exaggerated claims of ZFS features here>. After all, backups come in handy not just done to recover from a fire (where any technique that can restore the whole storage backend as quickly as possible is probably good enough). Far more ofter you will be faced with the demand to restore mailbox X to a previous state. Easily done with mountable read-only file system level snapshots as offered by ZFS or Netapp NFS shares. > > BTW, if you read German, or at least can gather what you need from > > some of the stats pictures, here's a 5 year old article > > on the subject. > > > > http://www.linux-magazin.de/Heft-Abo/Ausgaben/2007/06/Auf-der-Teststrecke/ > > Don't read German but thanks. What I got out of that is maybe I > should be considering Cyrus! :) Maybe not, the following is showing you the mean request response time (blue 200 clients, yellow 1000 clients): http://www.linux-magazin.de/var/linux_magazin/storage/images/media/linux_magazin/ausgabe/2007/06/auf_der_teststrecke/abb5_jpg/85577-1-ger-DE/abb5_jpg_reference.jpg And this image presents their measurements for LDA throughput: http://www.linux-magazin.de/var/linux_magazin/storage/images/media/linux_magazin/ausgabe/2007/06/auf_der_teststrecke/abb6_jpg/85580-1-ger-DE/abb6_jpg_reference.jpg Regards, Thomas > > > > On Thu, 2012-06-21 at 10:26 -0700, email builder wrote: > >> Hi, > >> > >> I'm a long-time Courier user and very happy with it (thank you, Sam). > > I'm currently tasked with spec'ing out what will be a high volume email > > environment and I'm a little concerned that Dovecot might be the better > > choice (due to indexing). I have only started to do research, so forgive > > me if > > I jump to conclusions. > >> > >> I'd like to know if anyone has practical or anecdotal advice about how > > Courier stands up to Dovecot under high use and what tweaks can be made to > > Courier to keep up. > >> > >> TIA > >> > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Courier-imap mailing list > Courier-imap@lists.sourceforge.net > Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-imap ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Courier-imap mailing list Courier-imap@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-imap
