On Thu, 17 Feb 2005 14:54:11 +0100 Marco Colombo <[EMAIL PROTECTED]> wrote:
> > 10-15MBps ... then add a few hundred concurrent pop & imap sessions plus > > some monitoring/statistical script walking your spool doing various > > operations and see this number fall down dramatically ... Because with > > random i/o ops you increase time disk heads travel around and add > > latency to the whole setup. Just came up with a test: if you have linux software raid, you can fail one drive and put it back, forcing a resync; then you can play with sysct dev.raid.speed_limit_min|max to establish a linear read/write i/o that takes some % of your total i/o capacity. Then add your above test to the mix and observe throughput numbers. Might be interesting :) > Consider splitting the SMPT incoming part from the IMAP/POP serving one. > Have the SMTP server receive, queue, scan messages. Once messages are in > the queue, use a queue runner to deliver message the IMAP server via LMTP. I think this goes by default? :) > Unless you are willing to accept mail for unknow users (and discover > that later at LMTP level) you may need to teach your SMTP server how to > recognize valid users. If you have some external db for user auth, it is relatively trivial to build a postfix (or sendmail..) map that checks for valid users before accepting the mail. What i'd like to see next is a overquota check on the same level. -- Jure Pečar http://jure.pecar.org/ --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
