After looking into it further, it's looking like my approach of writing a custom sampler to spin off sub-threads to do individual concurrent requests will not work. Correct me if I'm wrong, but JMeter bases its reporting off the one SampleResult object returned from the sampler's sample() method. So if each individual run of my sampler ran multiple requests via a number of sub-threads, I have no way of reporting the results of each of those individual requests. The best I could do would be to aggregate all the results of the individual thread requests in some manner and return that as the sampler's result. Is that correct?
Dave On Thu, Jun 16, 2011 at 12:15 PM, Deepak Shetty <shet...@gmail.com> wrote: > Hi > I played around with this awhile ago - perhaps you may get some hints > > http://theworkaholic.blogspot.com/2010/11/jmeter-and-ajax-part-i.html > > regards > deepak > > On Thu, Jun 16, 2011 at 8:59 AM, E S <electric.or.sh...@gmail.com> wrote: > > > Thanks for the advice. I did implement a test using the CSV Data Set in > the > > manner you speak of. That was a good first step, but I'm having trouble > > getting it to model exactly what I'm looking for. I agree that from the > > app's perspective, it doesn't know/care which thread is sending which > > request, but it does care that the requests are grouped together with > > respect physical locality on the map (adjacent tiles are requested in > > groups > > of 4). I think it would be difficult to craft the CSV files in such as > way > > as to make it dole out the proper requests so that it looked like > multiple > > different users are requesting tiles from different parts of the map at > > once, but still maintaining the spatial locality aspect. It would have to > > interleave groups of requests for different portions of the map and use > the > > Synchronizing Timer to group threads together to bundle up blocks of 4 > > request. Sounds tricky. It just seems way easier to write my code to do > > this > > by spinning off child threads in each user (JMeter) thread. Then when I > > want > > to ramp up the user load I just add more JMeter threads. > > > > Another approach I was thinking of taking was to write my own Java app > > outside of JMeter to do this and to simply have it output a valid log.jtl > > file, which I could view using JMeter. Not sure how well that will work, > > but > > it's something I might have to consider if writing the sampler is going > to > > be difficult. > > > > Dave > > > > On Mon, Jun 13, 2011 at 5:25 PM, Bruce Ide <flyingrhenqu...@gmail.com > > >wrote: > > > > > You'd determine which tiles you wanted to request in advance, and you'd > > put > > > that information in a CSV file. Then you'd write a test that requests a > > > tile > > > using information from the CSV data set. When you ramp up the number of > > > users (running threads) in your thread group, the CSV data set would > > parcel > > > your requests out equally among all threads. It does this one line at a > > > time > > > in the file, thread 1 gets the first line, thread 2 gets the second > line, > > > and so forth. > > > > > > As long as you build your CSV files to access adjacent tiles, it should > > > look > > > like a user with a browser to the application. You could even maintain > > > different datasets to simulate light or heavy usage. > > > > > > -- > > > Bruce Ide > > > flyingrhenqu...@gmail.com > > > > > >
