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