Test case implementation

---

To assess the cost of serialization in terms of time and CPU use, we developed a simple J2EE application without a database and recorded the time required for invoking a remote method with different objects as the parameters.

Application

The server included a stateless session EJB in the middle tier with interface methods that merely deserialize arguments and returned a timestamp. A Java servlet runs as a client on the same machine within the same JVM and middle tier.

The client is a Web browser that allows the user to choose between different objects and the number of iterations. The different objects vary in size and object complexity in terms of depth of structure. One object is a child of another object and yet another object implements the externalizable interface. The client chooses the appropriate object type, which is then used by the servlet on appropriate remote method of the EJB with the object passed as parameter to the remote function. The servlet records a timestamp just before passing the object. The server EJB receives a copy of the object and instantiates it to ensure a complete deserialization. The remote method then returns the current timestamp. The servlet uses this returned timestamp to compute and display the total time for completing the requests.

The cost of serialization and deserialization is estimated by comparing the cost of using local and remote versions of the EJB. With J2EE 1.3, EJB 2.0 local interfaces are available to developers. To measure the CPU use we used the Windows performance monitor when 100,000 iterations per user of the remote method invocations were used. This implies that the object was serialized and deserialized 100,000 times during a run. The average response time is calculated for a transaction where one transaction completes 1000 remote method invocations. When the local version of the EJB was used, there is no serialization and deserialization because the target EJB is known to be instantiated in the same JVM and objects are passed by reference. In WebSphere Application Server 4.0, the local EJB behavior was mimicked by explicitly indicating to the JVM that it was safe to pass objects to the EJB by reference.

Figure 6-2 shows the user interface that was used to measure the time to complete a single iteration with or without the local interface. The difference in response times, in a sense, indicates the cost of object serialization and deserialization. If the rate of transactions is recorded at the same CPU level, the difference in transaction rates is another indicator of the serialization costs.

Figure 6-2: User interface of simple application

Figure 6-3 shows the different objects used in the test with their relationships in a unified modeling language (UML) diagram. The code listing is provided at the end of this chapter.

Figure 6-3: UML diagram of objects used

The main LoadRunner script used the following dotype1000() function, 100 times for each load virtual user. This function defined the main transaction with a 1000 iterations of a certain object type.

 #include "as_web.h" dotype1000() {    web_url("BMClient",    "URL=http://9.30.134.61/SerializationDemo13Web/BMClient?iter=1000&type=11",       "Resource=0",       "RecContentType=text/html",    "Referer=http://9.30.134.61/SerializationDemo13Web/Bmindex.html",       "Snapshot=t11.inf",       "Mode=HTML",       LAST); return 0; } 

Environment

This analysis examines the performance in terms of time for a complete serialization / deserialization transaction at certain CPU utilization for WebSphere Application Server, Version 5.0 on Windows 2000 Advanced Server.

Figure 6-4 shows the simple test topology, consisting of one multiprocessor machine and a LoadRunner controller on a different machine.

Figure 6-4: Test topology

Figure 6-5 shows a snapshot of the Load Runner and Windows performance monitor.

Figure 6-5: Tools- Load Runner and Windows performance monitor

---