jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adrian Speteanu <>
Subject Re: simultaneous socket connections per server when downloading components for a page.
Date Wed, 03 Nov 2010 07:37:51 GMT
Hi guys,

These threads are juicy...  I would like to add 2 things:

 - first, if you test embeded resources and you get bad results - what then?
There isn't much that can be improved because it's handled by the container
which you take it as it is (not more then what tools like YSlow already tell
you anyway - without load tests!). It's been said in the list time and time
again and my opinion is that load tests had to be done way before your
application has such resources. You have to find ways to test avoiding any
dependencies. For some apps, it's hard, true - take it like a challenge.

 - second, if we talk about ideal test-tools we should also talk about
ideals applications: such applications that will have HTML and the interface
developed completely separated, which will make possible testing server
performance and benchmarking the interface separately with different tools.
That's the only way you can make one server perfomance test and estimate how
your app does on several browsers. In such a case we won't be talking about
why jmeter can't measure rendering, because it won't matter. However, there
aren't that many applications that have these components developed
independently, they usually go hand-in-hand. Rich interface applications are
designed to look good rather than be tested easily (good looking apps you
can sell).

This is not such a big issue because clients with such applications adapt to
real-life behaviour of their application and rarely rely solely on test
results. They shouldn't be advised to rely just on test results. Even more,
the IT of firms with big applications often have tricks up their sleeves to
handle these uncertainties, but mostly they just wait and see if it cracks
:) and just adapt then. Developing an ideal application and testing it with
the perfect tools is more expensive than this approach which in the end
works. However I sympathise with everybody who has to load test such
applications. Been there and most probably will run again into such

There is a point to this, that tests can't cover all posibilities no matter
how good is the test tool. In the case of new apps you can't really estimate
real users behaviour and in the  case of  working applications, mirroring a
percentage of the real load and give it to your test system seems to me a
better idea to decide how your app is behaving. JMeter is really useful to
generate load and find bugs that occur in load / stress conditions only
before getting at a stage when you can do test with real data. But it's more
important then doing the best tests ever what you monitor on the server
while testing, how can you identify bottlenecks in the application when
something seems fishy.

It's a lot more to this then what I have said and there are tons of
situations, with different specifics of their own - I am aware.


Anyway, it doesn't sound like a bad idea to have multiple tcp/ip connections
possible for a single thread (even if I disagree with the reasoning of
testing embeded resources and such). If it would be available, it might turn
out to be a useful enhancement. Can you currently work around this with
beanshell ? (let's say that you are really good with java, can you do this?)

Regards and keep up the good work,

On Tue, Nov 2, 2010 at 6:48 PM, sebb <> wrote:

> On 2 November 2010 14:17, Felix Frank <> wrote:
> >>> 1. Yes, it does even out. In the case of real users, requests will
> arive
> >>> in "groups" of, say, 8 parallel requests, but your server still has to
> >>> service them. 100 clients on a page with 20 embedded resources will
> make
> >>> 2000 requests. The fact that real users do them in parallel matters
> >>> little. To the servers, there are far more requests than it can
> actually
> >>> handle in parallel, so serialization *will* happen.
> >>>
> >> This is a case of poor capacity planning if the the servers cannot
> handle
> >> the load. Ideally there should be as little serialization as possible
> which
> >> ensures high customer satisfaction. If there are past examples of poor
> >> performing systems which you have come across, that doesnt mean the
> future
> >> has to be the same too.
> >
> > In stress test scenarios, you will want to overload your servers,
> > regardless of their power.
> >
> > In other load test scenarios, this may indeed be undesirable, and your
> > mileage will then vary to a greater degree because Jmeter serializes.
> > That's true.
> >
> >>> To put it differently: Given enough threads, the server sees high
> >>> parallelism in requests, and there is no need for the client to try and
> >>> introduce a "higher" degree of parallelism. The server won't notice a
> >>> difference.
> >>>
> >>
> >> The server wont notice a difference but the real time clients would.
> There
> >> is a need for stimulating actual customer behavior otherwise it would be
> >> hardly any high quality load testing.
> >
> > You can always turn to Selenium for absolute realism. But to induce the
> > same levels of load this way, you will need a *lot* more hardware than
> > for a Jmeter test.
> >
> > Take your pick.
> >
> > Jmeter is and should not be Selenium.
> >
> >>> 2. Please see the earlier thread. Deepak Shetty explained in-depth why
> >>> Jmeter (nor any other tool any of us know of) will give you an exact
> >>> estimation. I believe it was this thread:
> >>>
> >>>
> >>
> >>
> >> If there are no tools currently in the market, then we should build such
> >> tools. Because customers like reality!
> >
> > I'm not stopping you.
> >
> > I do question your assumption that this is within Jmeter's scope, though.
> Agreed - JMeter started life as a server stress tester, and that is
> still its main function.
> BTW, it's not possible (in general) to emulate how a browser behaves,
> because every browser behaves differently.
> E.g. IE 6 and 7 behave differently, and each browser can be configured
> differently by the user.
> > Regards,
> > Felix
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > For additional commands, e-mail:
> >
> >
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message