Friday, July 23, 2004
Writing an email for one minute burns 2 calories. How do I know that? Well, the August issue of National Geographic tells us that's true for a 150 lb person (as opposed to taking that 1 minute walk to your colleague's cube, which would burn 4 calories). I daresay you'd burn as many calories updating your blog for a minute. Hmm... cognitive dissonance!
Some notes on Web Services performance
I've been called into doing some software mercenary work for another product group here. This product provides a web services gateway using Apache Axis and after successive iterations of tests it was found that the server-side SOAP stack was the chief bottleneck. The team had moved from Axis 1.0 to 1.1 during the performance test cycle and had observed some modest gains, but not nearly enough. I found out that they were using the
In the
The
Now in the
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
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.
rpc/encoded
style SOAP encoding. Now this is probably the most developer-friendly of the 3 encoding styles -- rpc/encoded
, rpc/literal
and 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.
In the
rpc/encoded
model, 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.
The
rpc/literal
is 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/encoded
model, the overhead here is just of serializing and de-serializing a single parameter.
Now in the
document/literal
model, 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/encoded
as 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 document/literal
.
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
Apparently the only way one can configure the pool size for EJBs within WebSphere 4.0.x and 5.0.x is by specifying a system property for the container. Neither the desployment descriptors, nor the Application Assembly Tool, nor the WAS Admin Console allow you to easily set the min and max pool sizes.
Instead, you must set a JVM argument
They might as well tie our hands behind our backs.
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
MSN Search now looks eerily like another search engine -- one that I favor. The New York Times reminds us that Microsoft's greatest hits have been clones of other people's successful work, including Windows (based on the Macintosh), Pocket PC (PalmPilot) and Internet Explorer (Netscape Navigator). Ouch!
Click here if you do not have a login for NYT and do not want to give them your personal information.
Click here if you do not have a login for NYT and do not want to give them your personal information.
Friday, July 02, 2004
Don't go swimming if you have diarrhea
That's the advice dished out by the Early Show on CBS this morning. Yes, we all needed to be told that.