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

The Aliens, there in it with the spammers

[Anonymous Coward]

And if there was no spam, I doubt there would be such a need for these machines.

Re:The Aliens, there in it with the spammers

[British]

Perhaps the next generation of mail servers will devote 90% of its resources to filtering out spam, 10% for storing the rest(being legit emails).

Yes, the future is not how much mail you can store/process, it's how good your spam processing is, to save those 2 legit emails from grandma.

Oh oh .....

[Ganniterix]

Looks like spammers have a new tool ...

Re:Oh oh .....

[LiquidCoooled]

Constructing templated emails and blasting them out to multiple servers doesn't require a full mail server.
They are better using customised software which doesn't care about inbound mail.

Re:Oh oh .....

[Anonymous Coward]

Oh really, and you would know about this how exaclty?

The only way I can see you having this knowledge, is if in fact you are just a dirty great spammer

He's a spammer!

Burn him, burn him.

Re:Oh oh .....

[LiquidCoooled]

Shhhhhhhhhhhhhhhhhhhhhhhhhhh!

I don't want everyone to know.

By the way, are you interested in some viagra?

Old Koreans Rejoice!

[LiquidCoooled]

There will be partying in the care homes when this news spreads (via email of course).

That's a server consolidation booster

[TarryTops]

Now that's what I call a server consolidation booster!

I always thought gamers drove performance.

[mikeophile]

Turns out it's really spammers.

Re:I always thought gamers drove performance.

[CdBee]

In other news, Intel announced a multi-million dollar deployment and support contract sold to OptInRealBig.com....

Correction

[lbmouse]

"Rather than clustering a lot of smaller servers together, large ISPs can now use fewer systems to handle massive spam load."

Spam filtering?

[FridayBob]

Of course, you can always opt to include some stronger transport filter rules. Since most email is spam, this could make your MTA over 50% faster...

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

Solaris is not BSD

[Splatypus]

SunOS was BSD based, but Solaris never was.

Re:Solaris is not BSD

[putko]

Are you sure? The Wikipedia says otherwise.

I'm not saying the wikipedia is necessarily correct -- but what's your source that says Solaris is not based on SunOS (and not based on BSD)?

Thanks in advance.

Re:Solaris is not BSD

[Anonymous Coward]

Solaris is based on SysV.

Re:Solaris is not BSD

[Splatypus]

I'ved used Solaris and SunOS, and know the differences.

See this snipit from the Solaris Transiton Guide where they explain how to install the SunOS/BSD compat packages, and how to use the new Solaris commands http://docs.sun.com/app/docs/doc/805-6331/6j5vgg6a i?a=view

Or see the notes at the bottom of this page http://www.math.psu.edu/guide/node104.html

Re:Solaris is not BSD

[cnettel]

Solaris 1.x was running on SunOS 4. Solaris 2.x (that includes 7, 8, 9, 10) are running on SunOS 5. Remember, they (at some point) wanted you to call it the Solaris Operating Environment, versus the operating system, which would be only SunOS.

Re:Solaris is not BSD

[duffbeer703]

Solaris 1.x was a retroactive marketing name. SunOS 4 was what it was really called.

Re:Solaris is not BSD

[khb]

You could just read the source and compare. I believe you will find that (just as advertised) it's SVr4 and not BSD down deep. But why take someone else's word for it, use the Source .... http://opensolaris.org/os/

Unneeded

[Anonymous Coward]

Real World performance of any email server can be increased by blocking any IP allocation without an abuse@ contact availiable via IP whois. Yes APNIC & LACNIC, that basically means your assignments! You can also block comcast and res.rr.com by RDNS for a further significant reduction in unsolicited mail.

Why would anyone want to increase processing for the benefit of spammers?

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

Redundant?

[Puls4r]

No, not the post.

Isn't part of the allure of smaller systems handling the specifically to get away from large dedicated systems that aren't nearly as reliable?

By now, google should have taught the world something - distributed computing with small cheap specced systems that can each be swapped with multiple redundancy is the way to offer both uptime, speed, and be cost effective.

It's nearly identical to the "lean" manufacturing techniques pioneered by the Japanese. Small cells that can increase or decrease output based on the amount of workers (systems) that are working that day. Very flexible.

After all, it's a COMPUTER.... do you really want it dedicated to just email, or can we use it for other tasks in the downtime.

Re:Redundant?

[Jeff DeMaagd]

Isn't part of the allure of smaller systems handling the specifically to get away from large dedicated systems that aren't nearly as reliable?

The allure of small systems is because of COST, not reliability. Large systems are and can be very reliable. Using consumer commodity computer parts by themselves is more likely to be less reliable, but if you set up failover clusters, then you get a cheaper overall system that is as reliable.

Re:Redundant?

[saider]

I did a little "reliability analysis" for some telecom equipment a while ago, so I am semi-informed (not a guru).

There are two terms that often get interchanged, when they shouldn't. Reliability is the ability of the system to run without repairs. Availability is the ability of the system to do its job.

So the large monolithic system can be built out of very good (and expensive) components that do not fail as much as commodity hardware. This will lead to fewer failures and better reliability.

The commodity hardware can be arranged so that redundancy ensures that if on component fails, then another will take its load. Since the damaged component needs to be serviced, the reliability is lower, although the availiability of the system is the same.

Reliability is used by planners to determine the labor costs in keeping a system running. Availability is used by planners to make uptime predictions and to take measures to provide a certian level of service.

Two similiar numbers that are used for different purposes.

Re:Redundant?

[Anonymous Coward]

The allure of small systems is because of COST, not reliability. Large systems are and can be very reliable. Using consumer commodity computer parts by themselves is more likely to be less reliable, but if you set up failover clusters, then you get a cheaper overall system that is as reliable.

As the number of systems rise, the probably that one of those systems is down also rises. While the Google system works, it does so because the data is replicated: even if the machine goes down, the data it held is on n other machines (which hopefully are still up).

If the user's mail is on the system that is down, and only on that system, it doesn't matter much mail you can handle--you've just lost data.

Doesn't this create SPF?

[Anonymous Coward]

Using massive systems for handling mail invites a single point of failure (SPF), whereas using clusters of smaller systems for the same amount of money gives failover capability.

Of course, ISPs won't realize this.

Re:Doesn't this create SPF?

[Erwos]

I was under the impression that Communigate Pro had a clustering mode.

-Erwos

Re:Doesn't this create SPF?

[sk8king]

5 frontends in the test and 4 backends according to http://slashdot.org/comments.pl?sid=159258&cid=133 37970 7 of those machines could go down and mail would still be delivered [as long as 1 front end and 1 backend remained up]. Makes it great for upgrading one machine at a time with zero downtime.

Re:Doesn't this create SPF?

[Anonymous Coward]

Just having fewer servers doesn't necessarily mean greater reliability. You have to think of administrative costs in terms of SA time, monitoring software, licensing, etc.. If you are able to decentralize your administration, then yes, you can scale more readily. But it isn't a slam dunk for small systems over large systems.

Larger systems sometimes don't have the I/O bandwidth limitations that the smaller ones do. When pushing large volume email, even little things like having multiple CPUs so one CPU can push data on and off the network another can process the email is useful. Also, with partitionable servers today, you can take larger boxes and split them into smaller boxes, taking advantage of larger backplanes and similar without some of the SPOF issues that used to exist.

In one case I know, we had two types of systems doing a job. The first system type was single CPU, single everything, basically a pre-blade blade. The second system was exactly twice that. Two CPUs, etc. The second server type could handle five times the traffic without breaking a sweat. Smallness has its limits.

That said, a very large ISP I am familiar with moved to dozens of extremely small boxes to handle email last year. Don't say that ISPs don't understand the value of multiple smaller boxes. But there is an inherent infrastructure cost in having enough of those small boxes to make up the power of a single large (or pair of medium sized) systems. Since many ISPs already have infrastructure for large systems, the infrastructure cost of one more large system is already paid for. Many smaller systems would mean some new infrastructure that may not be in place.

Oh and by the way, wouldn't exchange be the best email system under this approach since you have no choice but to use huge numbers of small systems just to handle the load? (Sarcasm for the humor impaired)

Re:They use Solaris [BSD still dying]

[DenDave]

LOL!

Of course there is still life in BSD! Not everything is run on Win/Tux!!

And don't forget MacOSX is a BSD at heart.

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

[varmittang]

Well, thats nice for Apache, but this was 12,500 a minute. And if I can use a calculator correctly, thats 60*24*12,500 = 18,000,000 a day. As for your commercial place that does 50M, you might be exaggerating, but anything 2M and over is more than good enough for most businesses. I really wonder how much Exchange can handle now since there is no MS setups or Exchange setups on that list.

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:Not that great

[Matts]

As I said, their 12,500 a minute is a pure delivery figure - it does not include spam and virus filtering. These things make a HUGE difference to throughput on a mail server.

Re:Not that great

[Matts]

Replying to myself...

So reading the full disclosure they used 4 quad xeons. That's 16 CPUs. Compared to apache.org's 2.

So using a pure perl SMTPD you can have this kind of throughput (~1m mails per day per CPU) with spam and virus filtering enabled.

No, I am not impressed with this benchmark.

Re:Not that great

[Hew]

> Firstly I assume this is just a raw delivery setup

It is not. In addition to the SMTP service, the benchmark models POP3 service as well. From the FAQ, http://www.spec.org/mail2001/docs/faq.html :

"SPECmail2001 is an industry standard benchmark designed to measure a system's ability to act as a mail server compliant with the Internet standards Simple Mail Transfer Protocol (SMTP) and Post Office Protocol -Version 3 (POP3). The benchmark models consumer users of an Internet Service Provider (ISP) by simulating a real world workload. The goal of SPECmail2001 is to enable objective comparisons of mail server products."

Re:Not that great

[Anonymous Coward]

With SPECmail, the issue isn't how many messages per
second can your kick ass SMTP server handle; it's how many (simulated) concurrent & slow modem dial up POP connections (many), IMAP connections (some), and
other dross can the overall system handle. Again,
concurrently. And SPECmail does lean very heavily
towards simulating a world with the overwhelming
majority of users looking like POPers with dialup
modem connections.

So, while being able to handle lots of inbound messages per second and delivering them to your
message repository is important, there are other
factors too and some of them more heavily
weighted.

Re:Not that great

[Temkin]

Very interesting... The wording leaves one thinking Intel & BlueArc are announcing this. In fact the SPECmail report shows CommuniGate submitted the results. Why would Intel want to push a disk array that uses a Freescale PPC chip?

Re:Not that great

[dodobh]

We handle over a million messages a minute on our inbound MTA farm (25 boxes). This does not include mail being sent by our users, webmail, pop3 or imap traffic.

FWIW, mail is primarily a disk function. Use lots of fast SCSI disks in RAID 0 for maximum speed (or battery backed RAMdisk for the queue, incredible performance gain).

Re:Not that great

[Anonymous Coward]

FWIW, mail is primarily a disk function. Use lots of fast SCSI disks in RAID 0 for maximum speed (or battery backed RAMdisk for the queue, incredible performance gain).

Is the RAID 0 (striping only, no redundancy) a typo? Why bother with expensive battery backed RAM if a failure of any of your disks will take out the entire array?

Re:Not that great

[dodobh]

I was referring to pure speed. Both battery backed RAM and RAID0 give you pure performance gains.

If you want reliability as well, battery backed RAM, RAID01 or RID 10 would be a preferred choice.

We run RAID 5 for NFS mounted mail stores, and RAID1 on the frontend MXes. What we have though is a split between outbound SMTP gateways, IMAP servers, mail stores, POP3 servers, webmail servers, frontend proxies, MX servers, optional A/V scanning. Lots of little boxes and horizontal scaling.

Sadly...

[confusion]

Sadly, the need for that much capacity is probably driven by spam, which means ISPs are spending a boat load of money to facilitate spam that neither they, nor their customers want, and the ISPs have to turn around and charge higher prices because of it.

Certainly, any ISP worth its salt is going to be filtering spam, but there aren't a lot of anti-spam systems out there that are effective over the long term or aren't annoying as all hell.

Jerry
http://www.cyvin.org/

Re:Sadly...

[Anonymous Coward]

That is why we went to the Communigate cluster. The single server setup could not handle the viruses/spam that was coming in.

Clusters are not cheap either. Licensing/hardware costs are on the order of 10-15x higher than the single unit system. That is where the cost of spam comes in.

Re:Sadly...

[Bert64]

The whole industry is full of situations where you're forced into spending lots of money to solve problems that shouldn't exist in the first place..

Right, but...

[thc69]

...imagine a beowulf cluster of these...

*sigh*

for NFS

[mparaz]

If you would look at the details, the mail cluster uses NFS. Invented at Sun.

Re:for NFS

[Anonymous Coward]

NFS is the biggest piece of crap ever invented. We are currently experiencing a 3 day outage of all UNIX workstations due to an NFS issues.

Re:for NFS

[Anonymous Coward]

AFS outages are twice as fun.

What they don't tell you...

[mrRay720]

67% more mail, 250% higher cost! Well maybe not, but they're still only telling half of the important story.

Really though - is this really a useful metric - x million emails per day? Anyone needing this sort of mail throughput is going to be either a megacorp with a centralised mail server (do any actually do this?) or an ISP. If you're talking this level of mail you're already using some multi-box mail system. In that case individual box performance isn't so important, but rather costs.

In essence - for anyone needing this kind of system, "$x per email per day" has got to be a better metric than the useless "one single box, we won't tell you how much it costs, can do x million mails per day".

Re:What they don't tell you...

[clarkc3]

not sure about that 250% higher cost figure - we are in the processes of switching to communigate pro where I work because it cost a fraction of what it would've been upgrading to the new version of Sun One.

On an NFS message store

[Temkin]

Interestingly enough, they set their record using a message store mounted on NFS. It had 140 FC/AL attached disks, and 14Gb of RAM.

Virtually every file handle an MTA writes to is opened "O_SYNC". One of the quickest ways to make Sendmail or other common MTA's go fast is to mount their delivery queues on a solid state disk. I'm betting this disk array is turning around the queues without ever committing the data to the platters. (Not that there's anything wrong with this...) I am left wondering if there isn't some bit if NFS trickery not reported in the config.

But looking at the Sun entry, the old record was set using 2 year old software, and a much smaller disk configuration. Sun will probably update their entry in the near future, just to reclaim the crown. Email is much more an I/O problem than a CPU problem. Sun used to push their mail server on much larger HW, but most ISP's don't want to buy big boxes these days. The small to medium sized boxes, connected to a SAN are more cost effective, permit redundancy and easier maintenance.

Re:On an NFS message store

[Tet]

But looking at the Sun entry, the old record was set using 2 year old software, and a much smaller disk configuration.

Indeed. It doesn't strike me as being a particularly impressive record when there are only a total of 18 entries submitted, and most of them are 3 or more years old. I'm sure that I could quite easily come up with a system capable of beating the previous record for a reasonable cost simply by using modern hardware and minimal configuration tweaking.

Re:On an NFS message store

[Anonymous Coward]

Yes, on an NFS (or perhaps SMB) store.

The interesting bit is that the storage is pure hardware; there is no PCI bus or general purpose CPU between disk and LAN slowing things down.

Re:On an NFS message store

[Temkin]

The interesting bit is that the storage is pure hardware; there is no PCI bus or general purpose CPU between disk and LAN slowing things down.

The SPECmail report says it's a Freescale MPC7457B PPC chip, and specifically mentions NFS, not SMB. http://www.freescale.com/webapp/sps/site/prod_summ ary.jsp?code=MPC7457&nodeId=0162468rH3bTdG8653CPU Info Here

Sure looks like a general purpose CPU to me. Same family as used in the current Mac PB's, iBooks, and the Mini, with a bunch of speedy I/O stuff bolted on. This really isn't all that interesting a disk array. The Sun T3 used in the previous record is conceptually similar, though smaller. More importantly it uses FC/AL attach to the server, and this is NAS via NFS. I'm a big fan of networking, but this strikes me as one of those places where you're better off with a dedicated storage I/O channel like a FC/AL.

I'm left wondering why they chose NFS attach, and why Intel is mentioned as announcing this, since it promotes a Freescale processor in the disk solution, and from the actual SPECmail report, CommuniGate did the testing. Quite dodgy... I'd be a bit pissed if I were Intel.

Re:On an NFS message store

[puppetluva]

We evaluated BlueArc. . . we didn't choose it because it was "too new" in the market, but its network filer has unbelievable performance (Note: I don't work for BlueArc and it makes me a little queasy to support a commercial product).

BlueArc does all of their fileserving via microcoded hardware. Instead of using a plain old OS to build the fileserver, they do it in hardware modules dedicated to the task. This means that there is no OS overhead and the different modules (TCP/IP, CIFS, NFS, iSCSI, etc) have their own memory and work together in a pipeline. The performance they get from this is really sick. (Think one Bluearc machine is 3 times faster than a cluster of the highest end Netapps).

Behind the hardware front-end, you have a hardware raid-system that is long on cache (It's actually the raid unit from Engenio -- formerly LSI) with shelves configured with raid 5. Bluearc actually treats all of these raid-5 shelves as disks that it does raid-1 across. This gives you redundancy and double-striping in hardware from end to end. Did I mention that it was fast? It is - just check out specs.org to see how fast the thing is.

Re:On an NFS message store

[Anonymous Coward]

The CPU is only for state handling. All the heavy lifting is done by FPGAs.

Re:On an NFS message store

[Donny Smith]

>(Think one Bluearc machine is 3 times
>faster than a cluster of the highest end
>Netapps).

Their controller throughput seems to be 20Gbps - I'm lazy to check but I think I've seen one or two vendors with better performance.
http://www.bluearc.com/html/products/titan.shtml

>Bluearc actually treats all of these raid-5
>shelves as disks that it does raid-1
>across. This gives you redundancy and
>double-striping in hardware from end to
>end.

Don't all high end disk arrays work the same way? You create storage groups, then you create RAIDs of those.

> just check out specs.org to see how fast the thing is.

http://specs.org/? WTF?
Does this web site have a BlueArc NAS back-end?

Re:They use Solaris [BSD still dying]

[hatrisc]

actually this isn't true either. MacOSX has a FreeBSD based compatibility layer, but in reality is Mach based. This also causes some problems. The guy at http://www.kernelthread.org/ recently had a contest which was based on a huge problem with the way processes are handled in the compatibility layer and how certain things arent actually ever seen to mach. Thus causing kernel panics in certain situations.

Translation

[gorus]

Translation: spamming overtakes porn in driving computer technology forward. Senators everywhere rejoice.

Re:They use Solaris [BSD still dying]

[Bert64]

Hyperthreading is a nasty kludge, it splits the cpu into 2 virtual processors instead of a single superscaler processor.. The reasoning behind this, is that 2 poorly written apps which couldn't otherwise take advantage of a superscalar processor, can run simultaneously...
The side effect, is that apps which can take advantage of superscalar processors end up only seeing half of the processor and half of the cache.. So, modern apps (or apps compiled with modern compilers) actually lose performance due to hyperthreading..
Also, hyperthreading has been the cause of a number of security issues lately.

Re:They use Solaris [BSD still dying]

[cnettel]

It's been shown that you can mount timing attacks by the cache usage patterns. This is due to the fact that the cache is NOT cut in half, rather, all the cache is shared. If one thread stalls, or doesn't use floating point/vector operations, while the other one does, there are clear benefits of hyperthreading. It is HARD (impossible?) to use all of the execution units in a "wide" CPU all the time. Real benefits are reaped if the threads have good memory locality, while running diverse instructions. It is not pointless and it's not overly insecure.

And in other related news...

[LoganTeamX]

Intel says this entire performance increase goes away if you use AMD processors. Why performance goes away when you use a chip that doesn't need its own mini-nuke for a VRM is beyond me.

Well

[Progman3K]

It says a lot about the state of things when something like the fact that an e-mail server can handle millions of messages per hour makes the news.

Wake me up when there is a news item about how all the pornography on the Internet has suddenly disappeared.

Re:Well

[Anonymous Coward]

Wake me up when all the pornography on the Internet has suddenly appeared on my computer!!!

Re:Well

[Isvara]

Wake me up when there is a news item about how all the pornography on the Internet has suddenly disappeared.

If all the pornography on the Internet disappears, I don't want to be woken up :-(

Re:Well

[Anonymous Coward]

It says a lot about the state of things when something like the fact that an e-mail server can handle millions of messages per hour makes the news.

Yes, it says you're visiting a news site that caters to nerds.

Re:Well

[Anonymous Coward]

Wake me up when there is a news item about how all the pornography on the Internet has suddenly disappeared.

http://www.freespeechcoalition.com/

Read up on 2257, an amendment to US law that will pretty much end the use of any form of intimate (not just explicitly ponographic) photography on US websites. A lot of sites have gone down or changed recently because of it...

idea

[MERVERNATOR]

what we need to do is build LESS capable servers than we have now so spammers cant get as much through.. and use that slow time to both track down the persistent ones and develop better filters, not faster servers. better technology = better abuse of technology.

Re:idea

[Anonymous Coward]

Err, I don't believe that's possible.
Because: -

1. You're either going to kill the server by overloading it with mail it can't process fast enough - DoS attack;
2. You can't send the mail back and ask the sender to send it after 10 mins - when the server is free - due to clear implications on mission-critical businesses, such as Hospitals.

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 :)

And how does this impact Australia?

[AnotherEscobar]

Thats all I want to know

My previous company did 100M a day!!

[RouterSlayer]

So how the hell is this a record?
the company I used to work for (a spammer) - hey, I had to eat!
they were sending on AVERAGE about 100 MILLION emails a day by using a cluster of 100 small (1U) racked machines.
and we just used POSTFIX. running mostly K6-2 cpus, yeah real old stuff. lots of K6 cpus too.

so how the hell is this a new record?
oh I guess because spammers don't do the SPECmail tests... hehehe

Well they're 1/3 of the way to a simple postfix config. keep working on it guys!

Re:My previous company did 100M a day!!

[Anonymous Coward]

the company I used to work for (a spammer) - hey, I had to eat!

I'll take the moral high ground and call you a cunt.

I do accept that you have to eat, though.

- Moomin

Re:My previous company did 100M a day!!

[japhmi]

they were sending on AVERAGE about 100 MILLION emails a day by using a cluster of 100 small (1U) racked machines.

From the blurb:
Rather than clustering a lot of smaller servers together, large ISPs can now use fewer systems to handle massive traffic load."

Reading TFA, is sounds like this is one server - not 100. Unless the system in the article is using 30 servers, they beat your evil-spammer-boss's system on a per-server basis.

Not a record for sure....

[Anonymous Coward]

We were doing nearly 2 million per hour using an intel box in 2001 at NBCi/Xoom... using qmail running on redhat in a almost stock configuration. The hard part is getting all those emails out of a database and throttling how they are sent. Its pretty easy to set off big time spam alarms if server at bigdomain.com happens to get 10,000 or so emails in matter of minutes.

Communigate Pro

[Spent Casings]

My old web firm used Communigate Pro and we always found it to be a highly reliable and stable system. Their support used to be handled by one of their lead programmers and was top notch.

Record?

[chrome]

This can't be right. Right now, I manage a system that does 500,000 messages/day running of 8 IBM 306 boxes with FC3 & Exim and a NFS backend. Its pretty small, most of the companies I know here in japan are 100 times bigger than us and must easily break 50M messages/day ... docomo alone must do 500M/day ...

And the idea that one would need commercial software to do this is laughable ...

A bit of math

[AnuradhaRatnaweera]

The world population is about 6000 million people. Considering that not all of them read mail (e.g.: infants) it's not too way off to assume that average number of mails that a person can cope with is around 10.

If this box can deliver 30 million messages, 2000 of them are going to saturate the email limit the human civilization can handle (6000 x 10 = 60,000).

But there is a catch: this is under the assumption that all those 60 billion mails are not spam.

In other words, this record breaking "system" has no market in a spam-free world!

Re:Not that great - try RTFA

[MarsBar]

This isn't just a mail relay, this is (from spec's site):

A standardized mail server benchmark designed to measure a system's ability to act as a mail server servicing email requests, based on the Internet standard protocols SMTP and POP3. The benchmark characterizes throughput and response time of a mailserver system under test with realistic network connections, disk storage, and client workloads.

So that includes users connecting, picking up email, deleting from their data store etc etc etc.

Disclaimer: I have two friends who work for Bluearc but have no other connection to the company

yet another

[Anonymous Coward]

ad

Munitions?

[KFury]

Considering that the main cybersecurity (sorry) threats today are viruses and phishing attacks, how long might it be before super-high-volume email systems will be classified as munitions that require licensing and export restrictions?

Imagine if Nigeria got the e-bomb...

Funny math.

[Spazmania]

BlueArc's Titan sustained a performance level of 12,500 SPECmail messages per minute, or the equivalent of two and a half million SPECmail users, sending 30 million e-mail messages per day.

The math seems a little off...

12,500 messages/minute * 60 minutes/hour * 24 hours/day = 18M messages/day, not 30M.

That having been said, CGPro is fast as all heck so I can believe it topped the previous record.

RTFA

[Anonymous Coward]

The announcement came from BlueArc. They use Intel hardware. They use CommuniGate software.

WTF?

[sysadmn]

So you replace 5 Sun 480's with 4 1.2GHz processors with 9 servers with 4 2.4 GHz Xeons, and deliver mail to 2 million users instead of 1.5 million? Excuse me for not being too excited. Yes, 480's are expensive - wonder what a 4 way dual core V40z would do.

OLD NEWS

[Anonymous Coward]

Network Commerce (now chaper 7) was sending 60 million a day with 3 racks of 4U P3 servers & a few Sun boxes (just another reason to hate java) back in 2002. The day before they went chapter 11, they figured out how to double that amount.

(I knew the tech staff & they hated their jobs.)

The tester responds...

[thomtunes]

Just thought I'd add a few details and address some of the questions here. My name is Thom O'Connor and work for CommuniGate Systems (CGS), and was the one who put together and ran these tests - you can (mostly) verify this by looking at the comments in the source on the results page.

First off, on the SPECmail test itself. SPECmail is a standardized test (the only one I'm aware of for email) that attempts to closely regulate a level playing field for measuring email performance. It is critical to understand that this is not just measuring SMTP. The 30 million message a day text is a little vague, but it is important that this includes a distribution of delivery, relayed, and retrieved email. Sure, anyone can just relay many millions of messages an hour.

SPECmail does POP and SMTP, so the test measures not just MTA behaviour but also local delivery and then retrieval of the messages. The SPECmail test also uses Quality of Service (QOS) measurements such that a message injected via SMTP to the system MTAs (the CommuniGate Pro Frontend servers in this diagram) must then be delivered locally into the users' account, then be retrieved within 60 seconds. Satisfying the QOS criteria during the benchmark is often the most difficult part.

So, SPECmail itself just does POP and SMTP, which is a little 1990s I agree, but SPEC is coming out with a SPECimap test in the near future, and CGS is also very interested in seeing a SPEC VoIP/SIP test for measuring CommuniGate Pro's Real-Time capabilities.

A few others questions I've seen raised here:

1. The CommuniGate Pro Dynamic Cluster described in this test is fully and completely appropriate for production use in all aspects. In fact, if you're running a 2+ million user ISP on a CommuniGate Pro Dynamic Cluster, we'd recommend you to use these results as a guide for your architecture (although load balancers should be added to the gateway point for all inbound connections). In fact, CGS has ISP customers running architectures which match the layout of the described system almost exactly. All systems in the Cluster service all accounts - you could lose 4 Frontend Servers and 3 Backend Servers, and all users could still access their email (albeit with decreased capacity).

2. HyperThreading was disabled in the BIOS because the downloadable Solaris 10 x86 operating system would not (yet?) support the Intel x86_64 Potomoc chipset properly. That said, on top of the recent security vulnerabilities on the topic, we have also discovered miscellaneous threading and even NFS issues related to having HyperThreading enabled on Linux 2.6, FreeBSD 5.4, and Solaris 10 x86 systems.

3. On NFS...NFS is used safely and securely in this test. The integrity of data storage is one of the major criteria that the SPEC organization closely evaluates when reviewing a SPECmail submittal. Obviously, there are many ways to cheat and/or cut corners using Solid State Disks, unsafe RAM for message queueing, and other techniques that you would never want to use on your production message system. However, the test described here was performed using a standard (albeit excellent) BlueArc Titan Storage System with write caching only in NRRAM and using proper mount options and layout for security, redundancy, and data integrity.

Hope this clears up any misconceptions. Obviously, I'm clearly biased about the work here, but assembling and then passing a SPECmail test of this size is a gigantic effort. If anyone thinks

Re:The tester responds...

[sethmeisterg]

PLEASE report the hyperthreaded isue to your contact at Sun. If we don't know about it, we cannot help. The problems with hyperthreaded CPU detection is usually a BIOS problem; it has nothing to do with "chipset support" -- the Potomac is just another CPU, and there is a standard way in which BIOSes describe hyperthreaded CPUs (in ACPI tables).

Re:The tester responds...

[Anonymous Coward]

At the least one can submit a bug report at http://bugs.opensolaris.org/bugdatabase/index.jsp

Deep Spam!

[Jeremiah Cornelius]

The suppercomputer devoted to bulk mailings

Secret Alliance?

[i.of.the.storm]

Now we know why Intel has such dominance in the processor market, it has a secret alliance with spammers. (Buy AMD!)

Eh how is that a record?

[Anonymous Coward]

30000K or 347 mail per second does not sound that fantastic! I mean the Apache HTTP server can do around 2000 request per second on a standard PC today. If you do not factor in relaying the SMTP protocol is not that much different from HTTP measured in work per message, or did I miss something here?

400 Million messages a day

[dongshu]

I know of a cluster system that sends 400 million messages a day. If they have to use this BlueArc one, then they would still need a cluster of BlueArc mail senders.

The summary is completely wrong (as usual)

[seifried]

"Rather than clustering a lot of smaller servers together, large ISPs can now use fewer systems to handle massive traffic load."

From the testing reports linked in the article we have:

1. CommuniGate Pro Dynamic Cluster - Backend Servers (4 systems)
2. High Speed Network File Server for Main Mail Storage (1 system)
3. CommuniGate Pro Dynamic Cluster - Frontend Servers (5 systems)

For a total of 10 systems seperated into 3 levels (front end, backend, data storage).

High quality editing for Slashdot as usual.

Source: http://www.spec.org/mail2001/results/res2005q3/mai l2001-20050707-00039.html

Re:Not that great - try RTFA

[Matts]

So? Still no spam scanning. Still no AV. These figures aren't good, and I think CommuniGate is the bottleneck.

Re:They use Solaris [BSD still dying]

[DenDave]

Interesting, I was under the impression that when they said freebsd services they had taken it that much closer.. I stand corrected. http://www.apple.com/macosx/features/unix/

Re:They use Solaris [BSD still dying]

[hatrisc]

yeah, it's funny as most people see something about FreeBSD and immediately assume that the kernel is freeBSD. I think the gnu/hurd people were on to something when they decided to use mach. it is a great base for doing what you want. of course they have no changed their minds again (will we ever see a stable hurd?). Luckily OS X brings mach to life, and with it's user base growing and growing, i couldn't be happier to be using such an interesting kernel.