jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thom Hehl" <>
Subject RE: Advice
Date Fri, 06 May 2011 12:24:10 GMT
I really appreciate all the advice here. My comprehension of the basics
is "fumbling in the dark." :)

Yes, I'm really doing load testing, so I don't need much co-ordination
between the threads. All I need to make sure is that the UDP packets
start coming in before I start with the users, which I will use the
ramp-up period on the thread group. So I don't think this should be too
difficult. I'm using the UDPRequest Sampler that someone pointed me to
in an open source jmeter plugins project.

So the important things are that the UDP packets for a particular source
device must run in that order and that one packet arrive from each
device before I start HTTP testing. This is because the initial packet
from the source device does set up in the DB so it can be used by one of
the HTTP users reporting.

So if I understand what you're saying, I can assign the variables from a
CSV file, which I'm fine with. I think I can figure that out or assign
them in the UDV. This part is simple for me to understand.

What I can't seem to follow in the notes from you and Felix is how do I
tell each of my Sampler packets what thread it belongs to and how to
tell Jmeter to run those samplers as part of that thread.

I will face a similar problem when I reach the HTTP thread group because
I'll want each of the users to have their packets together as well.

Felix, I looked for "sholw plan" but couldn't find anything.


-----Original Message-----
From: Barrie Treloar [] 
Sent: Thursday, May 05, 2011 10:41 PM
To: JMeter Users List
Subject: Re: Advice

On Fri, May 6, 2011 at 12:50 AM, Felix Frank <> wrote:
> I cannot be much more helpful without knowing more specifics about
> 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
> 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

>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:

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

View raw message