Response to NServiceBus Performance

Udi, a man I respect immensely and has a great framework in NServiceBus, writes a post where he seems to do a lot of comparing to Neuron, comes up with some benchmark numbers, and then seems to call it "never really a comparison." I love the blog post, but I think you're really comparing apples to oranges.  For the Neuron ESB 28 million msgs/hour case study, the infrastructure was dramatically different than the one used to describe NServiceBus.

First, the customer in our case study had 1,500 geographically distributed workstations across the country, each one simultaneously acting as a publisher and subscriber to the bus in real time.  That's significantly different from the single data center (geographical location) scenario (which I'm assuming of course from the description above) with a dozen or so servers (also my assumption) perhaps acting as publishers/subscribers.

With most integration/enterprise service bus engines, thruput dramatically decreases as more subscribers are added to a system.  Both IBM and Sonic released graphs to our customer depicting such that demonstrated their software at 550 msg/sec wit 1 subscriber, decreasing to 50 msg/sec once they ramped to 100 subscribers.>P>

Fortunately though, Neuron ESB doesn't suffer from that degradation.

Also, with the Neuron case study, all 28 million msgs/hour were using our reliability layer for durable and guaranteed delivery, whereas only a tenth of the messaging in the nService was durable.

We didn't of course have 98 servers, however we did have 16 Neuron ESB servers and 1 database server.  Most of the Neuron ESB servers act as redundant servers, but once the customer upgrades to our 2.0 release, most of these servers will be removed, leaving perhaps 4 to do the processing work.  The number sits at 16 today because the customer at the time had a policy that software simply had to be installed on every server for redundancy.  Almost all of the existing Neuron ESB servers today are underutilized, which is another reason why we’re reducing them to 4 once the customer upgrades.

Our goal with Neuron ESB has always been to provide the most flexible, but easy to use .NET based ESB on the market….but one that doesn’t require large investments of infrastructure for the customer.  More infrastructure investments leads to more operational costs and complexity and greatly reduced ROI over time.  We like to think that Neuron ESB can go a long way to making these complex problems simpler for the customerAnyhow....quite different environments.  However, I do believe from everything I've read, you guys do great work!