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. Thanks! -----Original Message----- From: Barrie Treloar [mailto:baerr...@gmail.com] 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 <f...@mpexnet.de> wrote: [del] > 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. e.g. 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 correctly. 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: jmeter-user-unsubscr...@jakarta.apache.org For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org
