[KULRICE-4496] Speed Test: Soap vs java serialization for our remoted services Created: 27/Aug/10  Updated: 23/Feb/12  Resolved: 04/Apr/11

Status: Closed
Project: Kuali Rice Development
Component/s: Analysis, Version Compatibility
Affects Version/s: 1.0.3
Fix Version/s: 2.0

Type: Task Priority: Critical
Reporter: Garey Taylor Assignee: Eric Westfall
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PDF File Soap vs Serialization.pdf     File SoapTest.jmx     Text File recipe_service_patch.txt     Text File rice_MockIdentityServicePatch.txt    
Rice Module:
KIM
KAI Review Status: Not Required
KTI Review Status: Not Required

 Description   

Rice currently defaults to java serialization for remoting... instead of SOAP. This is primarily due to performance reason.

One issue with using serialization is that switching JVM's could cause differences in the way objects are serialized. ex. Java 5 client connecting to java 6 server.

We need to run some speed tests to see which is faster, soap or searial for remoted services.

For this particular case we upgrading the recipe sample app to spring 1.0.3 (snapshot) and tested that against the standalone server.
We created a simple servlet inside the sample app. All this servlet does is take in a request param to switch the underlying service call to use serialization or soap remoting.

Our test calls the identityService.lookupEntityInfo with an empty map. This will return a relatively large payload.

We're testing:
Soap vs Java Serialization

Oracle vs MySql

Soap Security On/off



 Comments   
Comment by Garey Taylor [ 27/Aug/10 ]

There seems to be very little difference in speed between java serialization and soap.

Comment by Garey Taylor [ 27/Aug/10 ]

There seems to be very little difference in speed between java serialization and soap.

Comment by Eric Westfall [ 30/Aug/10 ]

I'm assigning Jason to this. Jason, Garey and Jeremy have issues upcoming for our 1.0.3 version (which precedes the version compatibility work). I'm wondering how much of this sort of testing and metrics you're comfortable doing and whether you think that falls within the scope of the analysis work here?

Comment by Eric Westfall [ 30/Aug/10 ]

Note that ultimately, coming out of this we need to make a decision on whether or not SOAP in place of serialization will be feasible. This decision should be based on the results of the testing.

Comment by Eric Westfall [ 30/Aug/10 ]

I'll also leave this up to garey and jeremy a bit. If you guys would like to finish out running the tests and the numbers on this serialization stuff compared to SOAP then let's have you go ahead and do that.

Comment by Eric Westfall [ 30/Aug/10 ]

Setting Garey and Jeremy as co-assignees here. Savoir can work with them on this item.

Comment by Eric Westfall [ 30/Aug/10 ]

Here is a link to the google docs spreadsheet containing results so far:

https://spreadsheets.google.com/a/kuali.org/ccc?key=0AhXD6IrDu2YJdGlZMXhRZjY1clFBMDVuSE52ejdWMnc&hl=en#gid=0

Comment by Eric Westfall [ 30/Aug/10 ]

Added Jeff as a watcher.

Comment by Jason Whaley (Inactive) [ 31/Aug/10 ]

@Garey and @Jeremy: Do you have your current testing harness (and any modifications to the recipe app) committed?

@Eric: I may do a bit more with this just to provide some more numbers so that (hopefully) any speed concerns of soap may be quelled. It may be worthwhile to find another service to test also to remove any bias that identityService.lookupEntityInfo has.

Comment by Eric Westfall [ 31/Aug/10 ]

Jason, addressing your first question. I don't think we even have a test harness in the recipe sample application (sad as that is). I know that there is a version of the sample application that has been updated for 1.0.3, I think we need a version as well that will be updated for 1.1. It shouldn't be too bad to do this though because it will probably just involve updating a pom file to point to a rice 1.1.0-SNAPSHOT version (note you will probalby need to do a local maven install because we don't have 1.1.0-SNAPSHOT in our central maven repo yet). If you want, we can chat about how to go about doing that and creating the branch and whatnot. I need to check as well if you guys have commit access to the repository.

Comment by Eric Westfall [ 31/Aug/10 ]

Addressing your second question (the one to me): Some additional testing and numbers sounds good to me. It just helps for me to be able to point at those and say that performance shouldn't be a big concern here, especially since some of the Kuali stuff has had performance issues in the past and people get understandably nervous about such things, especially when you are proposing to make a significant technology change under the hood

Comment by Jeremy Hanson [ 01/Sep/10 ]

Creating mock IdentityService now. I'll add a patch to the jira when done.

I can add a patch to the changes we've made to the recipe app we are using and the jmeter test as well once I'm done.

Comment by Jeremy Hanson [ 01/Sep/10 ]

Attached rice patch for mock identity service. recipe sample app patch for new servlet which calls identity service, and jmeter test.

Comment by Jeremy Hanson [ 01/Sep/10 ]

To turn off security on the soap service, this goes in the config file:
<param name="kim.soapExposedService.jaxws.security">false</param>

Comment by Jason Whaley (Inactive) [ 11/Nov/10 ]

re-assigning this back to you to determine next action or if I or someone else need to do anything further.

Comment by Eric Westfall [ 08/Dec/10 ]

Probably all I need to do here to follow up is to ensure our results our documented and accessible somewhere. I'll probably get to that here in the next few weeks.

Comment by Eric Westfall [ 04/Apr/11 ]

I'm going to close this issue out. I think this plus the linked spreadsheet serve as documentation for the research done here.

Comment by Jessica Coltrin (Inactive) [ 23/Feb/12 ]

Closing since these items are now in the release notes.

Generated at Mon Apr 12 07:34:22 CDT 2021 using JIRA 7.0.11#70121-sha1:19d24976997c1d95f06f3e327e087be0b71f28d4.