For those of us who are always looking to optimize our code and improve performance by squeezing out a few milliseconds here and there, marshalling is one of those areas that you expect to be so bloated that you would think you could improve performance many times if you could get your hands on it.

This article will explore this area by running a set of experiments to actually understand the cost of marshalling in a typical J2EE setting.

Our experiments are based on a very simple test application. A servlet prepares an object, serializes it, and sends it to an EJB. The EJB de-serializes the object, serializes it again, and sends it back to the servlet, which in turn deserializes it. Quite simple as you can see; however, it touches on the basic points of a J2EE application server, the Web container, and the EJB container.

The test application has a handful of parameters. The first one allows us to specify if the object will be passed by reference or by value. The second parameter allows us to specify the type of object we want to use for the tests. We used only an array or a map of strings. The following parameter allows us to specify the size of the object, that is, the number of items in the array or map of strings.

Initial tests on our old Pentium III laptops showed us that the clocks of our machines (and operating systems) could not measure the response time of a round-trip of the application using an array of 1,000 items as it was far less than 1 millisecond. This did not meet our initial expectations that marshalling was expensive. Because of this we added another parameter (n) that allows us to define the number of times the servlet calls the EJB. After various tests we found that using n=1,000 was the best compromise for all the tests to obtain timing values manageable by the system clocks.

Our tests were conducted on an Intel Shasta computer with four CPUs (Xeon with HT at 2GHz) and 4GB of memory running Red Hat Linux AS 2.1. The application server was BEA WebLogic Server 8.1 running out of the box (all defaults) as an administration server. The only change was to enable HTTP tunnelling so that we could investigate the use of various protocols between server instances. The JVM used is JRockit 8.1 with the following parameters: -Xgc:parallel –Xms:1024m –Xmx:1024m.

The test application was implemented in a servlet so it could be conveniently invoked by altering query string parameters; for example, http://xeon:7001/marshalling/.

Every test was run 15 times and the data presented is the average of the last 5 runs. Table 1 presents the results in nanoseconds for an array with sizes going from 1 to 10,000 items.

 

As expected, passing by reference is very cheap, almost negligible. Passing by value is also quite cheap. Just consider that an array with 10,000 items was passed back and forth between the servlet and the EJB in only 173 nanoseconds per round-trip!

Using a map of strings (see Table 2) becomes more expensive, especially when passing by value, to the point that our laziness prompts us not to run tests using a map of strings with 10,000 characters as it takes too long for our threshold of patience (especially because we run every single test 15 times).

 

Once again, passing by reference is negligible. However, passing string maps by value is much more expensive than an array, but not as expensive as we would have expected. A map of strings with 1,000 characters will take 7.6 milliseconds to pass by value from the servlet to the EJB and back. That is two serializations and two de-serializations.

In running these tests we observed that the maximum CPU usage for the array tests was 2%, while for the string map tests it was 15%. Obviously working with strings maps is more expensive both in response time and CPU usage.

Since not everybody has the good fortune of working with such hardware and OS, we ran the same tests on a Compaq DL380 with two CPUs (Pentium III at 933MHz) and 1GB of memory running Windows 2000 Professional. The pass by reference tests had zero response time. We think this is because of the granularity of the H/W and OS clocks, so we will only show the response times for pass by value (see Table 3).

 

As you can see, hardware does make a difference. The cost of marshalling the map of strings by value is roughly double that of our previous tests. We also observed that the CPU usage on these tests was about 20% for the array tests and 50% for the string tests.

Obviously you want to use pass by reference when you know that your application is running on the same instance of WebLogic. Good thing WebLogic will automatically convert at runtime all pass by value to pass by reference when in the same .ear file.

With these results in hand, our curiosity moved us to look at how expensive it is to marshal between two computers over a network. We added a new parameter to our test application, which allows us to specify the location of the EJB. If not used, it assumes the same JVM.

Our next set of tests was exactly the same as the previous ones, but the difference was that we had the Web container in the Pentium III–based machine (P3) and the EJB container in the Xeon-based computer (Xeon). The network was isolated and traffic was generated only by the tests (see Table 4).

 

As you can see, the results are substantially more expensive than when running in the same JVM. Also, there is really no difference between passing by reference and by value. In both cases the information has to be passed back and forth between both computers, so it has to pass the values. The results for the map of strings are similar in nature (see Table 5).

 

However, we can't really say that things are that bad; after all, we are marshalling a map of strings of 1,000 items in about 22 milliseconds back and forth between two computers.

During these tests we observed that the maximum network usage was 40% of the 100 Mbps. The maximum CPU usage for the array tests was 15% on P3 and that of Xeon was 5%. For the string tests it was 25% on P3 and 5% on Xeon.

At this point we realized that we had the choice of transport mechanism. Namely, we could choose T3, the highly optimized RMI wire-protocol of WebLogic, or T3 tunnelled within HTTP.

We ran the same set of tests, but now using T3, and the results showed that for these tests plain T3 was faster than tunnelling it within HTTP. The difference is anywhere between 10% and 50%. In general, we observed that as the number of items in the object increase, the difference decreases. That is, the overhead of HTTP tunnelling is larger for smaller messages.

Another issue that became a concern was that the two machines used in these experiments were not the same, and that the direction of the tests could make a difference. The tests so far had been done by having the Web container in P3 and the EJB container on Xeon. So, would there be a difference in response times if we changed the direction and had the Web container in Xeon and the EJB container in P3?

We again ran all the tests changing the direction and noticed that having the Web container in Xeon was slightly faster. The difference was between 1% and 10%, which in general can be considered within the margin of error.

Based on the results of all of these tests, we can conclude that the cost of marshalling is not as expensive as most of us thought it would be. Passing objects by reference when in the same .ear file is the most efficient, and this is how WebLogic handles it internally.

When you have various instances of the BEA WebLogic Server running on different computers, there seems to be no difference between using pass by value and pass by reference. Finally, we observed that plain T3 is more efficient than tunnelling it within HTTP, although the difference tends to decrease as the number of items in the object grows.

Acknowledgments
I want to thank Phil Aston for writing the test application and his wise comments. Special thanks go to Intel for lending us the Shasta computer for running these tests.