jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Barrie Treloar <>
Subject Re: Advice
Date Fri, 06 May 2011 02:40:30 GMT
On Fri, May 6, 2011 at 12:50 AM, Felix Frank <> wrote:
> I cannot be much more helpful without knowing more specifics about your
> Test Plan. Most people just test HTTP. A common idea is to either have
> each thread use a distinct set of URLs from a CSV file, or read some
> specific parameters from CSV so each thread passes other information to
> the web application.

Because most people use plain HTTP you will need to dig deeper into
the documentation and do a lot more trial and error.

I recommend that if you find anything lacking in documentation to
submit patches to fix them.

I know I've found the Java sampler request stuff more difficult than
it needed to be, but I recognise I'm out on the bleeding edge here.
(I'm also simulating a UDP client sending/receiving packets to a UDP server)

>From your description of your test plan you should be able to get
JMeter to do what you want.

Where you will find problems is in coordinating thread communication.
I envision you having a test plan something like this:
* one ThreadGroup where each Thread in that group represents one
source of information.
Then in the test plan for that ThreadGroup you would load the UDP test
data assigned for that Thread and then sequentially send each packet
until it runs out of data. (Source ID probably assigned via CSV, from
the Source ID you can find the packets you need to send)
* one ThreadGroup where each Thread in that group represents a user
browsing the UDP data.
Then in the test plan for that ThreadGroup you would assign which UDP
stream that Thread will browse.

Because you have independent threads running you will somehow need to
work out how to know your "user browsing" test plan is working

Alternatively you merge these two ThreadGroups into one ThreadGroup
and at defined points in the test plan you "browse" instead of sending
a UDP packet to verify that what you are browsing is correct.

Perhaps this is tending too much away from "Load Testing" and into
"Functional Testing".
If your browsing plan just checked it got something sane back rather
than the details are what it expected that would make your tests
easier.  You will need to make the decision on how much effort you are
willing to put into the tests.

As an aside, how are you sending the UDP packets?
I had to write Java code implementing JavaSamplerClient in order to
simulate our application.

If you are writing Java code, then you can use a static class variable
as you "global" access point about how far a particular source has
reached and your user threads can verify that it can browse at least
that much data.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message