This is similar to what Ipswitch says. The problem is that 100,000+ is pretty open ended
I expect these numbers are Imail servers where there are 1) reasonable limit on mailbox size 2) 99% of mailbox access is POP (ie, not IMAP or webmail).
I've never heard anybody say they can run 100K users on webmail on one IMail machine, which could mean 5K or 10K simultaneous webmail sessions.
so I can only assume that it will handle up to 100k.
The first big number I heard from Ipswitch was 160K and that was in the P200 era, roughly, but it was before webmail and before imap.
they're not wasting cash on Xeon boxes when they could get by with a PIII.
fools and their money.... and you can't really prevent that, nobody is going to RTFM your guidelines.
I'm currently consolidating nearly 140 autonomous IMail servers and Ipswitch had little documentation at all to help guide us with hardware requirements. Without prior knowledge, we've had to discover how well the product scales as we go (support hasn't been very useful either).
It's a very complex situation to benchmark, so hardware overkill is the answer.
> >2) What is the best way to conceptually measure the performance of > >various components of an IMail Server? Specifically what metrics > >determine the actual performance of a system and what factors should be > >considered for determining performance bottlenecks and threshholds > >(processor / network / memory / io utilization, user response time, SMTP > >delivery time, messages processed per minute / day, external user > >databases, etc.)
The "big picture" is pretty simple:
smtp in/out is primarily disk i/o
POP reading is primarily disk i/o, and not interactive.
IMAP reading is primarily disk i/o, with the usual penalty of much larger mailboxes due to IMAP encouraging one to keep all mail on the server. IMAP is also interactive session oriented, so IMAP sessions and memory occupation tends to be much higher than POP.
webmail is the killer, since it is interactive, often running to many minutes or 10's of minutes per session, which requires the webmail app to hold open a webmail instance on the server for that long, for each interactive user. This strains CPU and memory, it also strains disk i/o since the webmail user is usually keeping all his mail on the server, needs a huge mbx (vs pop mailbox that is emtpied every connection), which in turn requires webmail to re-scan and re-index the mailbox every time a new message come is while the user is on-line to pull up the headers for browsing, and then there is the local disk i/o for MIME attachment processing, etc, etc.
The key for mail transfer and scanning is the number of E-mails > sent/received per day.
I hope to document a full range of performance metrics
I think you are wasting your time.
, so as to include hardware performance as it pertains to mail sent/received per day as well as per minute to account for peak usage performance constraints.
There are so many parameters in Imail alone, without or without rules (oh, how many rules? anchored or free? etc, etc), then your numbers will be useless to people who also run Declude and/or Sniffer, which are major consumers of resources.
I would also love to find a stress tool to push IMail's limits. If anybody knows of a free tool, please let me know.
Which specific, isolated part of Imail? smtp, pop, imap, webmail, disk i/o, rules, Declude, Sniffer, which AV scanner? and what about disk partitioning/allocation and level of fragmentation?
And of course, isolated component performance is useless for "real world" application, since nobody runs just one part, but a total system.
The complexities are immediately overwhelming.
If an IMail server is over-stressed, then an easy, proven de-stresser is to add IMGate.
And dedicated SMTP gateways, eg IMGate, should be in anybody's plans for scaling IMail to 100's of 1000's of accounts. This is how all the big ISP's handle SMTP scaling.
Furthermore, the 80/20 rule applies, and maybe it's even 90/10, where only 10% of the IMail servers are stressed and/or are posing scaleability questions. The other 90+% simply badly over-buy the hardware (eg, quad Xeon + 2 GB RAM and 320 MB/sec SCSI for 10k msgs/day).
Len
To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/
