Author: Holger Engels
From the operations point of view, an application divides into a server, a client and something that connects these two. While a single client normally deals with a single user, the server serves all active clients in parallel. The load and the resources of all clients accumulate in some way. A system "scales", if load and resources rise lineary with the number of parallel clients. Also with the number of clients, the probability of conflicts and deadlocks rise. The performance of a system on load cannot be predicted. It has to be measured. The Replay Tool of the SmartCC allows you to record a representative client session and replay it with an arbitrary number of simulated clients in parallel.
The org.smartcc.replay.RecordingInterceptor has to be configured for all ejb-refs that shall be included in the recording. The smart-ref definition may look like the this:
<smart-ref> <ejb-ref-name>ejb/RemoteTest</ejb-ref-name> <transport>org.smartcc.RMITransport</transport> <lookup>ejb/RemoteTest</lookup> <properties> java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory java.naming.provider.url=jnp://localhost:1099 </properties> <interceptor> <interceptor-name>org.smartcc.replay.RecordingInterceptor</interceptor-name> </interceptor> </smart-ref> |
It doesn't matter, what transport and other interceptors are configured. Now a representative usecase can be recorded. The result are two files:
Both together contain the complete information of all remote calls, that were recorded. For replaying, the Script uses the recorded parameters. The Script has to be compiled, of course:
export CLASSPATH=lib/ejb.jar:dist/client/ClientContainer.jar:test/build/local/TestApplicationClient.jar javac Replay.java
The shell script replay in the bin directory can be used to start the simulator. The application client jar must be contained in the classpath. The script takes the following command line arguments:
usage: simulator [options] client_jar script_class data_file user_range arguments: client_jar url of application client jar with deployment descriptors script_class full qualified classname data_file serialized arguments user_range 1-'lastUser' or 'firstUser'-'lastUser' options: -d, --delay [0..t] factor, that is applied to the recorded delays 0.0 for no delays, 1.0 for same tempo as during recording (default) -a, --auth the auth type, one of HTTP, JBoss (more to follow), defaults to HTTP -u, --userid the base userid, to which firstUser .. lastUser will be appended, defaults to 'demo' -p, --password the password for all users -i, --iterations number of iterations a virtual user runs the script, defaults to 'start' -r, --ramp load ramp, n'th client is started after n times the delay in ms, default is 0 -o, --output redirect output to a file |
Bear in mind, that the RecordingIntercptor should not be configured for replaying. Example for starting the replay tool:
export CLASSPATH=test/build/local/TestApplicationClient.jar:. bin/replay file:`pwd`/test/build/local/TestApplicationClient.jar Replay Replay.data 300