jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Deepak Goel <deic...@gmail.com>
Subject Re: simultaneous socket connections per server when downloading components for a page.
Date Tue, 02 Nov 2010 17:57:09 GMT
Hey

Namaskara~Nalama~Guten Tag

Please see below

Deepak
   --
Keigu

Deepak
+91-9765089593
deicool@gmail.com
http://www.simtree.net

Skype: thumsupdeicool
Google talk: deicool
Blog: http://loveandfearless.wordpress.com
Facebook: http://www.facebook.com/deicool

"Contribute to the world, environment and more : http://www.gridrepublic.org
"



On Tue, Nov 2, 2010 at 10:18 PM, sebb <sebbaz@gmail.com> wrote:

> On 2 November 2010 14:17, Felix Frank <ff@mpexnet.de> 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:
> >>>
> >>>
> http://jmeter.512774.n5.nabble.com/Test-plan-for-970-page-requests-every-5-min-td2826174.html#a2834078
> >>
> >>
> >> 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
>

What is does not have to be. Change is always required or we risk becoming
obsolete. Anyways, i think it is a major drawback that Jmeter cannot be
configured for multiple tcp/ip connections for a single user-thread. This
will simulate reality and also induce more stress quickly (which Jmeter
assumes now what is)

Most browsers would converge to the reality that one can download as much as
possible quickly moving to parallelism instead of serialism.

There are always exceptions though when a customer customizes a browser. One
could then customize Jmeter test too :) Hopefully!



> differently by the user.
>
> > Regards,
> > Felix
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>

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