:-) Ok, shoot again: what if 20,000 requests? Moreover, having 200 threads would not simulate exactly my use case (just 3 threads in my own client application).
I'm currently trying the thing with 2 separated samplers, I'll give you feedback. -----Original Message----- From: sebb [mailto:[EMAIL PROTECTED] Sent: lundi 22 octobre 2007 11:41 To: JMeter Users List Subject: Re: Asynchronous samplers On 22/10/2007, DELHOSTE Fabrice <[EMAIL PROTECTED]> wrote: > Thanks for your answer. > > > If there is always a response, why not send the request, and then > > wait > for the response? > > Unfortunately, that would limit my concurrent number of requests to > the number of sampling threads. And I want much more. > Ex: what if I want to simulate 200 concurrent requests made by 3 > client threads? Why not use 200 threads? > That's why I'm thinking about to make my request sampler not waiting > for response, returning a SampleResult related to the sending of request. > At the same time, I can build another SampleResult related to the > response that I just start in this sampler. > Then, a new "response" sampler could just wait for responses and > ending the SampleResult initiated in the request sample, for instance, > by sharing a Map of SampleResult as a variable between them. > > I've actually seen this kind of discussion in the history of the > mailing-list but there has been no follow-up... > > Fabrice > > > -----Original Message----- > From: sebb [mailto:[EMAIL PROTECTED] > Sent: samedi 20 octobre 2007 01:48 > To: JMeter Users List > Subject: Re: Asynchronous samplers > > On 19/10/2007, DELHOSTE Fabrice <[EMAIL PROTECTED]> wrote: > > Hi, > > > > I am currently trying to design a custom sampler upon an > > asynchronous request-response API and I haven't found enough > > detailed discussion on > > > that topic. > > JMeter does not support asynchronous working per se. > > > I basically want to measure the time from sending the request to its > > received response. > > If there is always a response, why not send the request, and then wait > for the response? > > This can be done in a single sampler. > > > As far as I understand, there may be a need for even-driven sampler > > in > > > the future but what's the best way to do it today? > > We have no plans to implement event-driven samplers. > > > I have first tried to add subresults on the SampleResult of each > > request when receiving responses (in another thread) without success. > > Tree of results were not correctly updated and I haven't found the > > way > > > to publish them as new SampleResult instead of subresult. > > > > So I'm thinking a bit more now :-) ... about separating completely > > the > > > request sampler from the response sampler. > > > > I would typically have 2 thread groups, one for request, the other > > for > > > response. > > The request sampler would send its request, not waiting for anything. > > The response sampler would listen for a response until some is > > received (using a shared lock with the listener initiated in request > > sampler), then return it as SampleResult. > > I would just send the request and wait for the response. > > Everything else would be a lot more work. > > > In theory, I would obtain on one side, all my request data, and on > > the > > > other side, my response data, that I would be able to correlate with > > my request...and then proceed naturally with all JMeter powerful > > stuff > > > on both groups. > > > > Before starting, I'd like to know if this seems possible to you. > > Any advice, or another way to implement? > > > > Thanks, > > Fabrice > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
