...
- 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 (this would require a text file called RequestClasses in the dir where the server program in invoked with each line containing a PERL5 regular expression to match specific URL's)
- 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
...
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 instance of jmclient.pl while there can be one instance of the server program jmserver.pl 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. (A gnuplot port should ofcourse be available on that OS.)
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.
| No Format |
|---|
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.
...
Communication between the one or more server jmserver processes and the single client
jmclient process happens via an XML string streamed through a network socket on each host.
The client program jmclient 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 jmclient then creates a hash of the results and passes the hash to an object that is essentially instance of Gnuplot.pm that as evident, is 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.
...
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.
There are some additional monitoring programs that I invoke as part of jmclient.pl. They should be commented out. Read the source code before using it.
...
Once again, make sure you read the source in all files before using. The program will not compile until you install all the dependencies and may have runtime failures too; but they should be easy to fix if you know a little perl or any other language.
I am yet to optimize jmserver – perl's hashes are not easy on memory, and jmserver takes a tad more CPU than I would've wished. But I will update the source here whenever I have a newer version of the libraries. You can fire comments/questions to the jmeter user mailing list.
Source: attachment:JmeterMeter.tgz