Thanks both, I am testing using jmeter on a master windows desktop with two slave injector machines, whilst my application is on an aix box. The tests running are request-response web services, so they send an xml soap message to an intergration layer, retieve a 'stubbed' response and then pass back an xml soap message. The difference between the two runs are they are just different services - which results in slightly different message size (at the most the difference would be 20 lines in the xml message). The latency I am talking about is the time taken between the initial request and the response received back.
My question is, with the slower test at 500ms, we know that the application/system must be able to cope with at least 7.5 threads simultaneously to achieve the thruput of 15per/sec. If we transfer this to the quicker test, processing 7.5 messages simultaneously a second, each message taking 250ms to complete, intuitively the thruput would be 30messages per/sec. So why is this not reflected in the thruput? I did think possibly we were overloading the system, but then surely that would be reflected in the latency, as overloading the system would slow down the end-to-end processing time rather affecting the injector machines? I would have thought the only way to have latencies that are twice the size in a test but having roughly similar thruputs would be if there was some kind of delay in sending the message (i.e. jmeter delays sending messages?) Any ideas as to what might be going wrong? Thanks again Rob On Sun, Mar 23, 2008 at 6:34 AM, Kirk <[EMAIL PROTECTED]> wrote: > Hi sebb, > >> > >> > > > > The latency is time to first response. > Is Rob not talking about latency in the call stack present in all of his > requests? > > If there are a lot of large > > pages, that may not scale. > > > If there are a lot of large pages JMeter, through no fault of it's own, > wouldn't be able to manage as bandwidth to the client would be the > biggest issue. > > Question I have was, what was different between the two runs? > > Kind regards, > Kirk > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
