Intel and BlueArc Set New Mail Server Record

louismg writes "With e-mail traffic continuing to explode, Intel and BlueArc announced this morning that the two companies have set a new SPECmail benchmark record in cooperation with CommuniGate Pro, offering a solution that can serve 30 million messages per day - 67% ahead of the previous record, owned by Sun Microsystems. Rather than clustering a lot of smaller servers together, large ISPs can now use fewer systems to handle massive traffic load."

Comments

Sun Solaris 10 x86

[Alex]

CommuniGate Pro Dynamic Cluster - Backend Servers (4 systems)
Software
CommuniGate Pro: CommuniGate Pro v4.3.6 Operating System: Sun Solaris 10 x86

CommuniGate Pro Dynamic Cluster - Frontend Servers (5 systems)
Software
CommuniGate Pro: CommuniGate Pro v4.3.6 Operating System: Sun Solaris 10 x86

Not that great

[Matts]

I didn't even know there was a SPECmail, but this figure doesn't seem too outstanding to me.

Firstly I assume this is just a raw delivery setup - no spam or virus filtering. You'd be amazed how much of a difference this makes to any real world setup.

Secondly, apache.org does over 2 million mails a day on a dual 2.4Ghz Xeon using an SMTP server written in Perl. And that's with full anti-virus (clamav) and lots of different anti-spam measures including SpamAssassin (which is known to be slow - I know because I used to be one of the developers).

I also know of commercial setups doing over 50m (legit, well - mostly) mails a day. Using an SMTP Server designed with performance in mind. Perhaps they should submit for SPECmail ;-)

So 30 million doesn't seem terribly amazing to me. Perhaps Communigate Pro isn't a very fast mail server.

Re:Not that great

[antic]

Probably worth noting that the Louis Gray who submitted this story is BlueArc's Corporate Communications Manager.

I thought that the blurb seemed a bit too slick to have come from anywhere but the company themselves. I hope there's no dodgy reason that Louis used a mac.com email address to submit the story instead of their work account.

Re:Spam filtering?

[Anonymous Coward]

Given that it takes more CPU and memory to filter mail than it does to deliver it, chanches are you could make your MTA deliver 50% slower

Speed vs. functionality

[IGnatius T Foobar]

The speed of any MTA is going to be determined largely by how much work is being performed when each message is submitted. The fastest MTA, therefore, is going to be the one that does the least amount of processing.

• How about that spiffy big Postfix or Sendmail box you've got sitting out there, whose sole purpose in life is to act as a relay? Sure, it'll process millions of messages per day. It doesn't have to do much.
• What if you're running a virus checker like ClamAV or a spam checker like SpamAssassin? Those take up CPU cycles. Sure, delivery is slower, but value was added.
• What if your back end mail system is something like the Citadel groupware platform, where MIME content drives an event handler system? Again, delivery is impacted, but the functionality of the system depends on it.
• What if your org has a global directory and your mail hub is responsible for making complex routing decisions for each message? Again, delivery is impacted; it'll be slower than the mega-fast-box, but mail won't be delivered correctly otherwise!

So you see, it's not always just about raw speed. And besides, next year's hardware will be faster anyway :)