There is a Redpaper which provides some excellent advice when it comes to tuning WebSphere ESB 6.0.2 for performance. However, you’ll have to wait a little bit for the Version 6.1 update. In the meantime, whilst all of the current best practice still stands, I thought I would post a couple of additional tips that are specific to the latest release.
Firstly, the move to a 6.1 WebSphere Application Server base brings with it the IBM Java 5 JVM. This alone is enough to give a performance improvement but it also provides a number of new garbage collection policies. A typical WebSphere ESB workload can result in the creation of large numbers of short-lived objects. Consequently, switching to use the generational concurrent garbage policy can result in shorter pause times and hence improved throughput under high load. This is enabled using the -Xgcpolicy:gencon
JVM option.
By default, this policy allocates 25% of the heap to the nursery space used for these short-lived objects. If you enable verbose GC you will see that in fact very little of the tenured space is utilized. Consequently, it usually pays to increase the proportion of the heap devoted to the nursery to around 75% using the -Xmn
option (e.g. -Xmn3g
for a 4Gb heap).
The second tip relates to transformations. In Version 6.1 you have the choice of using an XSLT or the business object mapper. There is no hard and fast rule as to which will perform better but it is worth trying both as in some circumstances there can be significant gains to be had. For example, in one case I’ve seen an improvement in throughput of 35% through switching from an XSLT to a business object map. One point to note is that the business object mapper will result in the deserialization of the request in to a service data object (SDO) with the performance overhead that this entails. This may not matter if the SDO is required elsewhere in the flow (for example to invoke a Java component) but, if not, you will lose the benefit of the lazy parsing that would otherwise have taken place.
Many thanks to Sam Massey and Callum Jackson for providing this information.
Hey – Thanks for this info. Amazing!
j@
An big reason ESB performance lacks is due to slow parsing of XML messages using DOM and SAX. The next generation XML parsing with VTD-XML can significantly improve ESB performance
http://vtd-xml.sf.net
Rest assured that IBM continues to invest in the parsing technologies used in its products.