webMethods has just released a new white paper on broker performance. Here is the link - [url=“http://advantage.webmethods.com/pro/whitepapers/wM6.5_IS_Broker_Publish_Subscribe_Performance_Dec.05.pdf”]http://advantage.webmethods.com/pro/whitepapers/wM6.5_IS_Broker_Publish_Subscribe_Performance_Dec.05.pdf[/url]
That link didn’t work for me, but after logging into Advantage you can find it in the Best Practices->Product Technical Notes area in the webMethods 6.5 category.
This tech note examines the publish-subscribe performance of IS in four key scenarios:
- Asynchronous Publish []Asynchronous Subscribe []Synchronous Publish [*]Synchronous Subscribe
The tests for each scenario were run with five different document sizes varying from 100 characters to
1,000,000 characters. Both volatile and guaranteed document types were tested. Some tests also compared performance using a single thread vs. five threads when applicable for that scenario.
Interestingly enough each scenario concludes with this observation:
OK, if the bottleneck wasn’t processor, disk or network throughput what was the biggest factor limiting performance? The article does not address this. The article implies that faster processors, disk subsystems or networks would not have improved performance. That doesn’t leave much to tune except perhaps memory (if that was, in fact a limiting factor) and the IS pub-sub architecture itself.
This also speaks to the viability of scaling webMethods IS horizontally rather than vertically. You could conceivably double the performance of the benchmarks measured in this test by adding a second IS behind a network load balancer.
Mark
Link is not forwarding after login for some reason, oh well. I liked the paper although I still wish they would do this across their major supported platforms with similar hardware. It really helps when try to compare OS’s and hardware.
We have done a lot of performance testing internally. I still continue to be impressed with just how fast the broker and the IS server are. They really are very efficient. The only real bottlenecks we run into are when we turn on auditing/w save pipeline(CPU does become a factor then as well as disk), complexity of flow services, and external systems added to the integration(latency).
The volume of transactions this software is able to pump through is pretty amazing.