deserialization speed

[necrosus]

Just a quick query as i would like to see if anyone else has had similar experiences as this.

Basically I am using jboss4.0.3SP1 (though the same thing appeared to be happending on jboss 4.0.2 as well). I have a stateless session bean which i expose via JBossWS using a document literal webservice.. One of the methods which is exposed has the potential to return a fairly large result set of xml (Nothing massive, a couple of hundred serialized objects and is approx. 200k in size.

What i have found is that my ejb method executes in around 150ms and that includes the parsing of xml clobs from oracle by castor (using a mapping file) of the information to be returned via the webservice. It then takes JBoss Axis approximately 6/7 seconds to deserialize this result to send back to a SOAP client. The time is definitely on the deserialization. I dont really know why this should take so long?

I decided to try and add in a bean simlar to WSMessageEndpoint which passed in and returned a w3c.dom.Element object. I found deserialization.. this time using the ElementSerializer took just as long.. again 6/7 seconds. Finally i have looked into just sending XML strings back and forth to skip serialization on the jboss axis server totally and this seems to do the trick and everything is back on the client and back in objects in around 600ms.

However, I dont want to have to do this. To me 6/7 seconds is way too long and is an unreasonable time to have to wait, so I think maybe I am missing something.. Does anyone have any ideas?

[thomas.diesler]

To me 6/7 seconds is way too long and is an unreasonable time to have to wait, so I think maybe I am missing something.. Does anyone have any ideas?

It is a well known issue that axis serialization/deserialization is dead slow.

Please have a look at the new stack jbossws, which is about to get released

http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3878875

I would welcome if you could share your experience with that on this forum.

[necrosus]

Thanx for the reply.. I will let know know how I get on
Is it worth trying out the early access or should I wait until the new stack is released?

[anders.hedstrom]

Hi,

I've done some testing in this area. I've developed a small benchmark application, see http://jira.jboss.com/jira/browse/JBWS-75

I've tested the benchmark app by deploying it on JBoss 5.0.0 alpha, JBoss 4.0.3SP1. Then I used SOAPSonar from Crosscheck and executed the performance test on echoArrayOfSimpleUserType. The array I was echoing containd 120 Simple User Types. The performance test was a duration test, it called the web service for 60 seconds. I got the following results:

JBoss 4.0.3SP1 - Total Requests=37, Average Request Bytes=11839, Total Request Bytes=438043, Average Response Bytes=11519, Total Response Bytes=426204, TPS=0.61, Throuphput (Bytes/Second)=14168

JBoss 5.0.0alpha - Total Requests=348, Average Request Bytes=11873.1, Total Request Bytes=4119970, Average Response Bytes=11839, Total Response Bytes=4108130, TPS=5.51, Throuphput (Bytes/Second)=130605

I've also implemented the benchmark app for AXIS and deployed it on Tomcat 5.0 with AXIS 1.1, then I got the following result executing the same performance test:

Tomcat5.0 w. Axis1.1 - Total Requests=3065, Average Request Bytes=11119.4, Total Request Bytes=34080900, Average Response Bytes=11119.4, Total Response Bytes=34080900, TPS=48.65, Throuphput (Bytes/Second)=1081930

Cheers

[thomas.diesler]

You don't have to wait. Use the JBossWS_1_0_Beta tag.

[necrosus]

You don't have to wait. Use the JBossWS_1_0_Beta tag.

I can't seem to build it at the moment, just letting you know to be helpful

This is the error

compile-classes15:
[javac] Compiling 171 source files to /usr/src/jboss/jboss-head/webservice/output/classes
[javac] /usr/src/jboss/jboss-head/webservice/src/main/org/jboss/ws/metadata/wsdl/xmlschema/WSXSDWriter.java:60: cannot find symbol
[javac] symbol : method getTargetNamespace()
[javac] location: class org.jboss.ws.metadata.wsdl.xmlschema.JBossXSModel
[javac] String targetNS = (jbxm).getTargetNamespace();
[javac] ^
[javac] /usr/src/jboss/jboss-head/webservice/src/main/org/jboss/ws/metadata/wsdl/xmlschema/WSXSDWriter.java:94: cannot find symbol
[javac] symbol : method getTargetNamespace()
[javac] location: class org.jboss.ws.metadata.wsdl.xmlschema.JBossXSModel
[javac] String targetNS = xsmodel.getTargetNamespace();
[javac] ^
[javac] /usr/src/jboss/jboss-head/webservice/src/main/org/jboss/ws/tools/ant/wstools.java:50: warning: [deprecation] project in org.apache.tools.ant.ProjectComponent has been deprecated
[javac] compileClasspath = new Path(project);
[javac] ^
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 2 errors
[javac] 1 warning

[jason.greene]

"necrosus" wrote:

You don't have to wait. Use the JBossWS_1_0_Beta tag.

I can't seem to build it at the moment, just letting you know to be helpful

The anonymous cvs is synced behind the RW cvs server, so perhaps you ended up with a partial commit. This change was recent though, so did you just do a plain checkout of head instead of the beta tag?

try checking out jboss like this

cvs co -r JBossWS_1_0_Beta jboss-head

-Jason

[jason.greene]

"anders.hedstrom" wrote:
Hi,

I've done some testing in this area. I've developed a small benchmark application, see http://jira.jboss.com/jira/browse/JBWS-75

I've tested the benchmark app by deploying it on JBoss 5.0.0 alpha, JBoss 4.0.3SP1. Then I used SOAPSonar from Crosscheck and executed the performance test on echoArrayOfSimpleUserType. The array I was echoing containd 120 Simple User Types. The performance test was a duration test, it called the web service for 60 seconds. I got the following results:

Just for curiosity are you building with jdk5?

-Jason

[jason.greene]

"necrosus" wrote:

You don't have to wait. Use the JBossWS_1_0_Beta tag.

I can't seem to build it at the moment, just letting you know to be helpful

The anonymous cvs is synced behind the RW cvs server, so perhaps you ended up with a partial commit. This change was recent though, so did you just do a plain checkout of head instead of the beta tag?

try checking out jboss like this

cvs co -r JBossWS_1_0_Beta jboss-head

-Jason

I take that back there is a problem. I will take a look at it.

-Jason

[jason.greene]

Ok the beta should build for you now. Thanks for the report.

-Jason

[anders.hedstrom]

Just for curiosity are you building with jdk5?

Yes.

[necrosus]

Hi,

I finally got around to looking into this. I got some of the same code deployed on JBoss 5.0 alpha, running EJB 3.0 with the new stack.

The updated stack immediately took off about 4 secs on the serialization time which is a massive improvement :)

I have a few questions in terms of some warning messages that were produced. Every one of my objects produced this message. Have i missed some obvious config?

[org.jboss.webservice.metadata.jaxrpcmapping.JavaWsdlMapping] Cannot find jaxrpc-mapping for type: {namespace}object

Also I am sure there are some links i have missed. If I am to deploy this properly for testing I think the more relatvely safe option for me is to deploy to JBoss 4 with a back ported JBossWS stack, as i want to mininize risk (eg the new jms in version 5 etc). I am not sure what is the best version of 4.0.4 to check out and if there are instructions about removing the jboss-axis stack.

thanx for any help

[thomas.diesler]

http://wiki.jboss.org/wiki/Wiki.jsp?page=WSDeployJBossWS

[johnr1111]

Another option to potentially look at is using Fast-Infoset. I don't know if JBoss supports it, and it's not supported outside of Java, but it's goal is to seriously reduce the serialization and de-serialization using a near binary representation.

A web service is exposed with both the Fast-Infoset and a normal non-binary one.. The selection can be made in the http hearders.

So a .Net client could invoke the web service with the non Fast-Infoset version and other java clients could invoke the Fast-Infoset model.

Microsoft is working on something similar in the upcoming Communication's Foundation (Indigo), so it sounds like there will be some time before it's agreed upon by all parties. In the end though, it sounds like it's going to happen in some form. This tied in with MTOM, will go along way to reduce the over-head and size of the data.