THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
- Completely dependent on jmeter.log
- Has several metrics to analyze the performance of jmeter itself and "client-end" measures:
- number of active/terminated threads
- requests per minute
- average response time
- average response time across last X% of requests
- average response time across last X% of test duration
- mean time between consecutive requests (a nice way to know when things are slowing down)
- number of waiting requests (request sent but not received response yet)
- grouping response times based on URL regex matching
- XML of results can be seen at anytime using a simple command:
telnet <host_running_jmserver> <port> - Results aggregation across hosts running jmeter
- Dynamic/near-realtime charting of results using a gnuplot script created dynamically
...
A client program that reads XML containing measures from one or more servers, aggregates them, dynamically generates a gnuplot script, and runs gnuplot to generate charts.
Architecture and limitations
The core idea behind this is that the server running jmeter should do nothing except just that – generate load. So aggregation of the various performance measures is done by a single client program while there can be one instance of the server program per jmeter instance gathering data from the jmeter log.
The code would only work on a linux distro once the dependencies have been installed. But anyone who knows a little perl can port it to other OS's.
Also, currently, the analysis is restricted to HTTP samples, but again, even that can be easily changed by changing a few lines in the server process.
It is necessary to have the following two settings in jmeter.properties.
log_level.jmeter.protocol.http.sampler.HTTPSampler=DEBUG log_level.jmeter.threads.JMeterThread=INFO
The root loglevel should be WARN to save IO overhead within jmeter.
Ofcourse, if you are trying to gather metrics on other samplers (JDBC,..) you should set the corresponding class at DEBUG level.
Communication between the one or more server processes and the single client process happens via an XML string streamed through a network socket on each host.
The client program aggregates results across servers and can optionally be made to invoke several child processes each of which can gather measures from other sources. For eg., I have a database statistics collector that collects the number of active/idle oracle sessions and the memory used by them to monitor database performance; another program that is invoked as a child that can collect system memory and CPU usage of arbitrary hosts running perhaps the application/database server; and so on.
The client program then creates a hash of the results and passes the hash to an object that is essentially a wrapper around the unix charting tool, gnuplot. It dynamically creates a gnuplot script the first time it is invoked with the results hash and from then on, keeps including the new results to dynamically generate charts.
Finally, you can create a simple html that shows the charts; I create a table in the html with each column/row corresponding to each test so that test results can be compared.
Usage
Make sure you install all dependencies. I run jmeter on linux machines – so this package may not be platform independent. But its all written in perl, so porting to other OS's should be easy once you know perl.
...