September 25, 2014

Starting load test with Grinder 3.0

Grinder 3.0 is one open source tool that will help you resolve all your challenges with open source tool with flexible control using its powerful language Jython which is a Java implementation of Python that is compiled to bytecode and runs on a JVM and the most powerful thing is it allows you to access Java libraries using Python Syntax.
There are typically 4 main components to Grinder,
Console: GUI that is used to control configure load test scenario, and displays the collected statistics that are reported back from the workers.
Agents: You will run one Agent from each load injector machine which will load configured number of worker processes. Agents connected to console will wait for a signal to start before passing off a local grinder.properties file to the worker processes.
Workers: They are the one that actually execute the load test scripts similar to load injector. The grinder.properties file that is passed to the worker by the agent which defines the script that the worker will execute together with number of  threads and complete load test scenario.
TCPProxy – It’s a script recorder which introduces proxy between browser and server, and records the flow of application which is later used by worker process.

Preparing load test Environment:
Install Java Standard Edition 6, equivalent, or later
Unzip Grinder after download  from http://grinder.sourceforge.net
Set CLASSPATH
Set your CLASSPATH to recognize grinder.jar and java
CLASSPATH to C:\grinder-3.11\lib\grinder.jar
JAVA_HOME to C:\Program Files\Java\jdk1.7.0_45
To Start Console/Agent/Proxy  create following batch files,
StartGrinderConsole.bat
java net.grinder.Console
To Start Agent create following batch file,
StartGrinderAgent.bat
java net.grinder.Grinder
StartGrinderProxy.bat
java net.grinder.TCPProxy -console -http > grinder.py
console : displays the console which can be used to add comments during the recording process and to shut the TCPProxy down cleanly.
http : Adds the request/response filters to produce a script readable by The Grinder’s HTTP plugin.
grinder.py : The script will be output locally to a file named grinder.py. You can rename this or relocate where it will be created if you like.

Create grinder.properties
Create grinder.properties under example folder of grinder, specify executable file, process and thread
grinder.script = grinder.py 
grinder.script : Name of the script that we will execute (e.g. grinder.py), and the path is relative to the exact location where file resides.
grinder.processes = 6
grinder.processes : Number of workers that the agent will start
grinder.threads : Number of threads each worker will start and each thread will execute the script.
grinder.threads = 5
grinder.threads : Number of threads each worker will start and each thread will execute the script.
grinder.runs = 0
grinder.runs : Its iteration or number of times each worker thread will run the script. 0 mean infinite loop.

Recording script with TCPProxy
Start TCPProxy by running StartGrinderProxy.bat
 In Internet Explorer browser go to Internet Options à Connections à LAN settings

Check Proxy server and set following value: localhost:8001

July 24, 2014

Explicit Full GC is enabled for RMI calls

This is rather strange behavior, but has been recently observed that whenever your application is exposed to services via RMI or it consumes any service over RMI, you will have another garbage collection cycle after every one hr. As explained in RMI documentation:

“When it is necessary to ensure that unreachable remote objects are unexported and garbage collected in a timely fashion, the value of this property represents the maximum interval (in milliseconds) that the Java RMI runtime will allow between garbage collections of the local heap. The default value is 3600000 milliseconds (one hour).”

This will overwrite your JVM algorithm, and will explicitly initiate Full GC.
If you don't want to have this GC happening every one hr than you can use following JVM argument -XX:+DisableExplicitGC   to control it.





May 12, 2014

Jboss Performance Improvements





To update the JBoss XML files: 

In JBoss XML files search for  \installation\jboss\standalone.xml
     Open the standalone.xml file in a text editor. and do the following:
a.       In the file, locate “urn:jboss:domain:threads:1.1” and under the code line, add the following:


<subsystem xmlns="urn:jboss:domain:threads:1.1">
            <bounded-queue-thread-pool name="default-thread">
                <core-threads count="3000"/>
                <queue-length count="500"/>
                <max-threads count="3000"/>
                <keepalive-time time="60" unit="seconds"/>
        </bounded-queue-thread-pool>
    </subsystem>

 

b.        In the file locate connector name="default" and in the code line add the following parameters after enabled="true"
executor="default-thread" max-connections="1000"
The line will look like:


<connector name="default" protocol="AJP/1.3" scheme="http" socket-binding="default" enabled="true" executor="default-thread" max-connections="1000"/>
c.        In the file locate connector name="live" and in the code line add the following parameters after enabled="true"
executor="default-thread" max-connections="1000"
The line will look like:


 <connector name="live" protocol="AJP/1.3" scheme="http" socket-binding="live" enabled="true" executor="default-thread" max-connections="1000"/>
d.        In the file locate connector name="pushlet" and in the code line add the following parameters after enabled="true"
executor="default-thread" max-connections="1000"


<connector name="pushlet" protocol="AJP/1.3" scheme="http" socket-binding="pushlet" enabled="true" executor="default-thread" max-connections="1000"/>