Concurrent HTTP requests to simulate AJAX client

[E S <el...@gmail.com>]

I have a fairly basic question about how well JMeter will support and
AJAX-based client. I am trying to load test an application in which the user
views a map in the browser. As they navigate around or zoom in and out, the
browser makes AJAX REST calls to a server to download the required image
blocks of the map (like google maps). Most browsers support making 4 or 5
simultaneous http requests. So to properly simulate a bunch of browsers
hitting the server all at once, I need each worker thread (the thread being
the "browser") to support sending out batches of 4 or 5 requests at the same
time.

How well will JMeter support this? Will I have to spin off and manage my own
threads within the worker threads or does JMeter provide any help with this?
Will JMeter be able to track statistics for each individual thread inside
each worker thread?

Thanks,
Dave

Re: Concurrent HTTP requests to simulate AJAX client

[sebb <se...@gmail.com>]

On 16 June 2011 16:59, E S <el...@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.

Why not group several URLs on a single line in the CSV file, and have
multiple samplers in the same thread access the URLs in sequence?

i.e. read URLs into variables A, B, C, D and have samplers for each in turn.

If you want to get clever, you could name the variables suitably for
use with the ForEach Controller.

> 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 <fl...@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
>> FlyingRhenquest@gmail.com
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org

Re: Concurrent HTTP requests to simulate AJAX client

[E S <el...@gmail.com>]

Yes, that does seem to have worked. I spin off the sub-threads then wait
using thread.join() until all the sub-threads are done. Then I call
result.sampleEnd() on the outer sample. Thank you, that was very helpful.

On Mon, Jun 20, 2011 at 12:43 PM, Bruce Ide <fl...@gmail.com>wrote:

> I believe you can hang subsamples off of the SampleResult object that gets
> created. Your sampler would just need to block until all subsamples have
> been returned, and it would have to know how to assemble them in the final
> sample (Which shouldn't be a terribly big deal.)
>
> I haven't done anything with subsamples myself, I've just noted that there
> seems to be that capability while digging around in the source code.
>
> --
> Bruce Ide
> FlyingRhenquest@gmail.com
>

Re: Concurrent HTTP requests to simulate AJAX client

[sebb <se...@gmail.com>]

On 20 June 2011 18:43, Bruce Ide <fl...@gmail.com> wrote:
> I believe you can hang subsamples off of the SampleResult object that gets
> created. Your sampler would just need to block until all subsamples have
> been returned, and it would have to know how to assemble them in the final
> sample (Which shouldn't be a terribly big deal.)
>
> I haven't done anything with subsamples myself, I've just noted that there
> seems to be that capability while digging around in the source code.

Yes, that's how Transaction Controller and HTTP download embedded requests work.

> --
> Bruce Ide
> FlyingRhenquest@gmail.com
>

---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org

Re: Concurrent HTTP requests to simulate AJAX client

[Bruce Ide <fl...@gmail.com>]

I believe you can hang subsamples off of the SampleResult object that gets
created. Your sampler would just need to block until all subsamples have
been returned, and it would have to know how to assemble them in the final
sample (Which shouldn't be a terribly big deal.)

I haven't done anything with subsamples myself, I've just noted that there
seems to be that capability while digging around in the source code.

-- 
Bruce Ide
FlyingRhenquest@gmail.com

Re: Concurrent HTTP requests to simulate AJAX client

[E S <el...@gmail.com>]

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 <sh...@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 <el...@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 <flyingrhenquest@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
> > > FlyingRhenquest@gmail.com
> > >
> >
>

Re: Concurrent HTTP requests to simulate AJAX client

[Deepak Shetty <sh...@gmail.com>]

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 <el...@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 <flyingrhenquest@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
> > FlyingRhenquest@gmail.com
> >
>

Re: Concurrent HTTP requests to simulate AJAX client

[E S <el...@gmail.com>]

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 <fl...@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
> FlyingRhenquest@gmail.com
>

Re: Concurrent HTTP requests to simulate AJAX client

[Bruce Ide <fl...@gmail.com>]

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
FlyingRhenquest@gmail.com

Re: Concurrent HTTP requests to simulate AJAX client

[E S <el...@gmail.com>]

I'm thinking I'm probably going to have to write my own sampler for this.
The reason being that the requests can't be for random tiles from anywhere
on the map, they have to be based on what would actually be requested if the
user were to pan around or zoom in and out. This is because we are putting
certain optimizations in place based on tile locality. I don't know that the
CSV Dataset element will provide me with enough control in terms of which
threads get which requests (though I'm not sure since I have pretty much
zero experience with it).

I would like each thread to work at a different location in the map so no
two threads requests the same tile. This is so I can take the cache we have
in place out of the equation (for now). That's probably going to require
some configuration and management at a higher level somehow. Perhaps the CSV
Dataset could aid in this aspect.

Dave


On Mon, Jun 13, 2011 at 1:31 PM, Bruce Ide <fl...@gmail.com>wrote:

> You could drop all the URLs you want to request into a CSV file. In your
> thread group you'd set the number of users to however many threads you want
> to use for your requests. The CSV data element can parcel the requests out
> between threads (it loads them into variables that are unique in each
> thread) and then you could make the requests simultaneously. As long as you
> use the variable from the CSV element as the URL for your request, that
> should work pretty well with a single thread group doing the work. For just
> stress-testing tile-getting, that's pretty easy.
>
> If you want it to do anything else while requesting tiles, or if you want
> it
> to start requesting tiles at one point in the test, and then stop later on
> (While still doing other stuff,) that could get more complicated.
>
> --
> Bruce Ide
> FlyingRhenquest@gmail.com
>

Re: Concurrent HTTP requests to simulate AJAX client

[Bruce Ide <fl...@gmail.com>]

You could drop all the URLs you want to request into a CSV file. In your
thread group you'd set the number of users to however many threads you want
to use for your requests. The CSV data element can parcel the requests out
between threads (it loads them into variables that are unique in each
thread) and then you could make the requests simultaneously. As long as you
use the variable from the CSV element as the URL for your request, that
should work pretty well with a single thread group doing the work. For just
stress-testing tile-getting, that's pretty easy.

If you want it to do anything else while requesting tiles, or if you want it
to start requesting tiles at one point in the test, and then stop later on
(While still doing other stuff,) that could get more complicated.

-- 
Bruce Ide
FlyingRhenquest@gmail.com

Re: Concurrent HTTP requests to simulate AJAX client

[oliver <ol...@hotmail.com>]

You could try this: 
http://jakarta.apache.org/jmeter/usermanual/component_reference.html#Synchronizing_Timer
Synchronizing_Timer 

You might have to play around a bit with the scope but it should do the job.

Ajax calls are still just HTTP requests though and they are asynchronous in
the sense that they are independent of the main page load but this will not
normally have a huge impact on server side traffic (the huge caveat there
being the word 'normally'.) 

That said, browsers these days are really taking up multi-threading so maybe
you have a good point.

--
View this message in context: http://jmeter.512774.n5.nabble.com/Concurrent-HTTP-requests-to-simulate-AJAX-client-tp4482655p4482737.html
Sent from the JMeter - User mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org