> only by counting mbytes in/out for an hour and dividing by 3600 > seconds.
You missed the point. That's EXACTLY what I'm talking about (along with message count and protocol preference): mbytes in/out, i.e. (in my vocabulary) "bandwidth consumption." I'm not talking about message-by-message breakdown! You have said multiple times (I won't bother fetching from the archives), and I agree, that a theoretical count of 50K users concurrently consuming resources is practically irrelevant (not to mention ridiculous)--only the resources to be consumed in planned use are relevant. This is true in any part of data network design. If you're rolling directory services out to 60 physical workstations and 50 people, it doesn't matter whether your platform can handle 1 billion objects, it matters how fast it can return results for the most complex lookups on those objects. And so on. > The expensive part of msg processing is disk i/o, the per-msg: > file SMTPD queue file create + > SMTP file find +open + > SMTP .mbx find + open + seek EOF + append The larger the average mailbox (inverse relationship to DELE frequency, user knowledge of other file-transfer methods, and preset limits on maximum mailbox and message size, as well as on basic message rate) the longer this step takes, obviously. Why else do we caution against super-large mailboxes? And those giant mailboxes are just plain hard to create with plain-text messages, and invariably have attachments (or are accidentally unattended). It's all related. > It doesn't really matter if the file avg size is 1k or 10k in all > the directory traversing and head movement. I would project that under load it matters considerably, given block size options and other configuration choices (though I might start with 20K). I will have to run the numbers, as usual. > and that's just the SMTPD/SMTP, gotta do it all again for POP and > webmail access. I fail to see how this disproves the importance of bytes in transit, (proves it, rather), but that wasn't my original point anyway. > Then later, add the clustering, which is much a smaller piece than > all the above, because the above involving the users where > clustering is backroom plumbing that the users don't see. Depends on which definition of clustering. If you took him to mean fully redundant hardware, but no new active IP addresses, true (except for what can be substantial downtime for an ISP while you cluster a server in-place to save money, instead of buying two new ones). But with other types of clustering such as peering, better to expect pop3-1 through pop3-10, rather than making people change server names later, and to plan your user management front end accordingly. Likewise for having multiple client SMTP gateways. This is more a question of nomenclature and management than actual purchasing, but if you skip it and you grow, it will bite you. -Sandy 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/
