Here is a description of the components planed for the JMS sampler.
- JMS publish sampler
- JMS subscribe sampler
- Sample aggregator
- Graph to display publish, subscribe and total in terms of kb/sec
- generic client class used by both Publish and subscribe sampler
The two samplers will have common properties, which users must provide.
- URL - Context.PROVIDER_URL
- Initial context - Context.INITIAL_CONTEXT_FACTORY
- ConnectionFactory - server specific setting
- Topic - the specific topic for the test
- Iterations - number of iterations to aggregate
- use 1 connection for N producers/consumers (suggested by james)
- use N/2 connections for N producers/consumers (suggested by james)
- use N connections for N producers/consumers (suggested by james)
- Message type - TextMessage, ObjectMessage
- random message - similar to how webservice sampler can randomly select a message
- Text area - for message
- Use as monitor - this is similar to HTTPSampler for Tomcat5. when it is checked, the sample is set as monitor result, which is then used by the monitor to display the health and performance
The sample Aggregator is needed to aggregate several samples together, since a single publish will probably less than 1 millisecond, it's a good idea to run X iterations and record the time.
By having a publish and subscribe sampler, it means a single test plan can have two thread groups running concurrently. One thread group can have X threads publishing, while the thread group for the subscribers can have a different number of threads. this should allow for a wide variety of test scenarios. Using the same connection for N producers/consumers will measure the effect of connection on performance.