[
http://jira.jboss.com/jira/browse/JBESB-1105?page=comments#action_12380444 ]
James Williams commented on JBESB-1105:
---------------------------------------
I have checked in some additional changes to address modularity issues in the original
scripts. Now, all logic live inside class declarations and the Agent/Reporter code is a
bit more re-usable. I also created a new LoadUtil.groovy script that breaks out reusable
MBean queries.
I also added JMS queue factor depth metrics. A negative queue factor means the queue is
filling up faster than it's being worked. A positive queue factor means the ESB
listeners are processing faster than requests coming in.
For example:
Queue Factor of: -.50 (means that in the last second 500 more messages were received than
processed)
Queue Factor of: .50 (means the ESB listeners have emptied 500 messages more than were
received)
Also, 2 report logs are now generated, one for queues and one for ESB services. I still
have some LoadReport.groovy script logic to clean up, but it's only to make the code
easier to manage and it will pave the way for a lightweight swing GUI visualizer.
James
ESB Should have a good load generation framework
------------------------------------------------
Key: JBESB-1105
URL:
http://jira.jboss.com/jira/browse/JBESB-1105
Project: JBoss ESB
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: Examples
Environment: I have created groovy scripts that simulate load and provide some
TPS metrics. I used an external Groovy 1.1-Beta as my test for these scripts. Groovy is
bootstrapped in the build script, so it's possible to swap it out with the ESB
bundled, but I do not know if I'm doing any 1.1 specific stuff.
Reporter: James Williams
Assigned To: James Williams
Priority: Minor
Original Estimate: 2 days
Remaining Estimate: 2 days
There are 2 groovy scripts. One script, JMSLoadAgent.groovy, simulates load by dropping
sample messages into a JMS gateway. There are a slew of properties entries to control the
throttling of messages, and the payload file can be specified outside of the groovy
script. This script is designed to be a template for other load scripts. For example, a
load script that drops files into a directory that has a file system listener.
The 2nd script, LoadReport.groovy, uses the JMX MBean stats at the service level to
report TPS. you can specify one or more services as a comma separated list. And, there is
a short circuit that will kill the reporter. The short cut is a bit crude, but it works.
You specify the fastest ESB listener queue. When that queue depth is at 0, the report
stops. The report will print out to the console, and to a properties file configured
location.
There are also several ant targets to run either the agent, reporter or both. I also
include a sample ESB archive to test the quickstart and the services are hardwired so that
one is distinctively faster than the other. These scripts should work for any service,
provided the user adds the proper entries to "load.properties".
There is no GUI for this yet, but I started out with a GUI, then realized that primary
benefit of the load framework is the stats dumped into a log file or on the console. All
other stuff is pretty straightforward with a simple properties file.
The readme.txt probably needs a little beef, but I'm going to go ahead and check this
in because I think it's going to be a very valuable contribution for users looking to
load test and identify TPS at the service level.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira