Friday, July 23, 2004
Some notes on Web Services performance
rpc/encodedstyle SOAP encoding. Now this is probably the most developer-friendly of the 3 encoding styles --
document/literal-- but not the most efficient. It brings to mind a couple excellent articles, one by Frank Cohen (Discover SOAP encoding's impact on Web Service performance) and another by Dennis M. Sosnoski (Cleaning up SOAP Web Services::Test Results) on the topic. The rationale is really simple.
rpc/encodedmodel, you call a remote object and pass requisite parameters. It is the SOAP stack's responsibility to serialize your request parameters into XML format and to de-serialize them into objects from the response XML. One can imagine that for complex objects and large payloads, this can have an impact on performance.
rpc/literalis a slight variation on the above. You can send raw XML data as a request parameter. The SOAP stack serializes this single XML data parameter, binding the request to the remote object. Unlike the
rpc/encodedmodel, the overhead here is just of serializing and de-serializing a single parameter.
Now in the
document/literalmodel, your request is actually an XML document. So is the response. The onus is on you to write the logic to extract the SOAP envelope's body element and parse the XML response.
So why do we choose development-time ease at the price of runtime penalties on scalability and performance? My opinion is this may be due to lack of awareness, not lack of diligence. That tools like Apache Axis (which is by no means the only one to do this) default to
rpc/encodedas the out-of-the-box encoding style only exacerbates the problem. I think Microsoft may have got it right in this case. The .NET implementations default to
I realize that Axis has a 1.2 beta out but do not know if any significant performance gains can be achieved with that. Going to production with a 'beta' version of an important cog in the wheel scares most decision makers.
Friday, July 16, 2004
WebSphere EJB pool morass
Instead, you must set a JVM argument
com.ibm.websphere.ejbcontainer.poolSize, which applies to all manner of creatures -- message driven, stateless and entity beans. Wonderful! The property value for any serious application looks cryptic, if anything. Read their documentation for details. When not specified, the values 50 and 500 are used.
They might as well tie our hands behind our backs.
Thursday, July 08, 2004
Look who got a facelift
Click here if you do not have a login for NYT and do not want to give them your personal information.