You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@jmeter.apache.org by sebb <se...@gmail.com> on 2010/11/01 11:28:45 UTC
Re: simultaneous socket connections per server when downloading
components for a page.
On 31 October 2010 22:25, <B....@eventim.de> wrote:
> Hi@all,
>
> My goal is to design a http load test in jmeter with a real life scenario. In this scenario it is necessary to simulate also the behaviour of the actual browsers. During my tests, I saw that jmeter use always only one tcp connection for each thread to download a webpage, but actual browser like Firefox use up to 8 tcp connections to download a web-page.
>
> Is there a way to open more then one tcp connection in jmeter?
No, not for a single thread.
>
>
> Thanks a lot
> bjoern
>
>
>
>
>
>
> ---------------------------------------------------------------------
> 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
Re: simultaneous socket connections per server when downloading
components for a page.
Posted by Deepak Goel <de...@gmail.com>.
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 5:26 PM, sebb <se...@gmail.com> wrote:
> On 1 November 2010 21:43, <B....@eventim.de> wrote:
> > Hi Sebb,
> >
> > I am not sure how I can interpret your answer. Is there a other way to
> simulate this behaviour?
>
> No.
>
> JMeter threads each use different connections, as the represent different
> users.
> Although you cannot run multiple connections to download page
> resources in a single thread, that's not generally a problem when
> testing servers, because this tends to average out over multiple
> users.
>
I thought about this and it is not the case. It doesn't average out.
>
> Just make sure that JMeter generates the required load at the server.
>
> > Thanks
> > Bjoern
> >
> >
> >
> >
> >
> > -----Ursprüngliche Nachricht-----
> > Von: sebb [mailto:sebbaz@gmail.com]
> > Gesendet: Montag, 1. November 2010 11:29
> > An: JMeter Users List
> > Betreff: Re: simultaneous socket connections per server when downloading
> components for a page.
> >
> > On 31 October 2010 22:25, <B....@eventim.de> wrote:
> >> Hi@all,
> >>
> >> My goal is to design a http load test in jmeter with a real life
> scenario. In this scenario it is necessary to simulate also the behaviour of
> the actual browsers. During my tests, I saw that jmeter use always only one
> tcp connection for each thread to download a webpage, but actual browser
> like Firefox use up to 8 tcp connections to download a web-page.
> >>
> >> Is there a way to open more then one tcp connection in jmeter?
> >
> > No, not for a single thread.
> >
> >>
> >>
> >> Thanks a lot
> >> bjoern
> >>
> >>
> >>
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> 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
> >
> >
> > ---------------------------------------------------------------------
> > 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
>
>
Re: simultaneous socket connections per server when downloading
components for a page.
Posted by sebb <se...@gmail.com>.
On 3 November 2010 07:37, Adrian Speteanu <as...@gmail.com> wrote:
> 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
> applications.
>
> 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?)
Yes, in theory you could parse the the HTML and download the
resources, adding them as children of the HTML page.
I don't know how difficult this would be.
> Regards and keep up the good work,
> Adrian
>
> On Tue, Nov 2, 2010 at 6:48 PM, sebb <se...@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
>> 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
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: simultaneous socket connections per server when downloading
components for a page.
Posted by Adrian Speteanu <as...@gmail.com>.
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
applications.
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,
Adrian
On Tue, Nov 2, 2010 at 6:48 PM, sebb <se...@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
> 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
>
>
Re: simultaneous socket connections per server when downloading
components for a page.
Posted by Deepak Goel <de...@gmail.com>.
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 <se...@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
>
>
Re: simultaneous socket connections per server when downloading
components for a page.
Posted by sebb <se...@gmail.com>.
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
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
Re: simultaneous socket connections per server when downloading
components for a page.
Posted by Deepak Goel <de...@gmail.com>.
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 7:47 PM, 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.
>
The answer was in regards to your example and not a stress test. And even if
it is a stress test, i think it is a drawback in Jmeter that it cannot have
multiple tcp/ip connections for a single user thread. Most of the browsers
would have parallel tcp/ip connections for minimum download time and
parallelization. So a stress test with parallel tcp/ip connections for gif
would be a better test than a stress test without tcp/ip connections. Your
servers would get stressed much sooner. :)
>
> 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.
>
> Regards,
> Felix
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>
Re: simultaneous socket connections per server when downloading components
for a page.
Posted by Felix Frank <ff...@mpexnet.de>.
>> 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.
Regards,
Felix
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: simultaneous socket connections per server when downloading
components for a page.
Posted by Deepak Goel <de...@gmail.com>.
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 6:46 PM, Felix Frank <ff...@mpexnet.de> wrote:
> Hi Deepak,
>
> to answer both your concerns:
>
> 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.
>
> 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.
>
> 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!
>
>
> Regards,
> Felix
>
> On 11/02/2010 02:06 PM, Deepak Goel wrote:
> > 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 6:00 PM, Felix Frank <ff...@mpexnet.de> wrote:
> >
> >> On 11/02/2010 12:56 PM, sebb wrote:
> >>> On 1 November 2010 21:43, <B....@eventim.de> wrote:
> >>>> Hi Sebb,
> >>>>
> >>>> I am not sure how I can interpret your answer. Is there a other way to
> >> simulate this behaviour?
> >>
> >> Your question sounds suspiciously like "how can I make Jmeter measure
> >> the time the browser will take to load my page and content"?
> >>
> >> There has been a lengthy discussion here on the topic a few weeks ago.
> >> The bottom line is: Jmeter can't and won't do this for you. It's not
> >> worth the hassle trying.
> >> Induce your desired load, and see how your server performs. It's not
> >> Jmeter's job to play browser and report accurate estimates on page
> >> display time.
> >>
> >
> > I would disagree. Thats what load testings tools are supposed to do.
> They
> > are supposed to play browser and report accurate estimates on page time
> > (simulating real time users)
> >
> >>
> >> HTH,
> >> Felix
> >>
> >>> No.
> >>>
> >>> JMeter threads each use different connections, as the represent
> different
> >> users.
> >>> Although you cannot run multiple connections to download page
> >>> resources in a single thread, that's not generally a problem when
> >>> testing servers, because this tends to average out over multiple
> >>> users.
> >>>
> >>> Just make sure that JMeter generates the required load at the server.
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
> >>
> >>
> >
>
> --
> MPeX.net GmbH / Werner-Voß-Damm 62 / D-12101 Berlin / Germany
> MPeXnetworks / www.mpexnetworks.de
> Tel: ++49-30-78097 180 / Fax: ++49-30-78097 181
>
> Sitz, Registergericht: Berlin, Amtsgericht Charlottenburg, HRB 76688
> Geschäftsführer: Lars Bräuer, Gregor Lawatscheck
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>
Re: simultaneous socket connections per server when downloading components
for a page.
Posted by Felix Frank <ff...@mpexnet.de>.
Hi Deepak,
to answer both your concerns:
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.
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.
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
Regards,
Felix
On 11/02/2010 02:06 PM, Deepak Goel wrote:
> 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 6:00 PM, Felix Frank <ff...@mpexnet.de> wrote:
>
>> On 11/02/2010 12:56 PM, sebb wrote:
>>> On 1 November 2010 21:43, <B....@eventim.de> wrote:
>>>> Hi Sebb,
>>>>
>>>> I am not sure how I can interpret your answer. Is there a other way to
>> simulate this behaviour?
>>
>> Your question sounds suspiciously like "how can I make Jmeter measure
>> the time the browser will take to load my page and content"?
>>
>> There has been a lengthy discussion here on the topic a few weeks ago.
>> The bottom line is: Jmeter can't and won't do this for you. It's not
>> worth the hassle trying.
>> Induce your desired load, and see how your server performs. It's not
>> Jmeter's job to play browser and report accurate estimates on page
>> display time.
>>
>
> I would disagree. Thats what load testings tools are supposed to do. They
> are supposed to play browser and report accurate estimates on page time
> (simulating real time users)
>
>>
>> HTH,
>> Felix
>>
>>> No.
>>>
>>> JMeter threads each use different connections, as the represent different
>> users.
>>> Although you cannot run multiple connections to download page
>>> resources in a single thread, that's not generally a problem when
>>> testing servers, because this tends to average out over multiple
>>> users.
>>>
>>> Just make sure that JMeter generates the required load at the server.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>>
>>
>
--
MPeX.net GmbH / Werner-Voß-Damm 62 / D-12101 Berlin / Germany
MPeXnetworks / www.mpexnetworks.de
Tel: ++49-30-78097 180 / Fax: ++49-30-78097 181
Sitz, Registergericht: Berlin, Amtsgericht Charlottenburg, HRB 76688
Geschäftsführer: Lars Bräuer, Gregor Lawatscheck
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: simultaneous socket connections per server when downloading
components for a page.
Posted by Deepak Goel <de...@gmail.com>.
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 6:00 PM, Felix Frank <ff...@mpexnet.de> wrote:
> On 11/02/2010 12:56 PM, sebb wrote:
> > On 1 November 2010 21:43, <B....@eventim.de> wrote:
> >> Hi Sebb,
> >>
> >> I am not sure how I can interpret your answer. Is there a other way to
> simulate this behaviour?
>
> Your question sounds suspiciously like "how can I make Jmeter measure
> the time the browser will take to load my page and content"?
>
> There has been a lengthy discussion here on the topic a few weeks ago.
> The bottom line is: Jmeter can't and won't do this for you. It's not
> worth the hassle trying.
> Induce your desired load, and see how your server performs. It's not
> Jmeter's job to play browser and report accurate estimates on page
> display time.
>
I would disagree. Thats what load testings tools are supposed to do. They
are supposed to play browser and report accurate estimates on page time
(simulating real time users)
>
> HTH,
> Felix
>
> > No.
> >
> > JMeter threads each use different connections, as the represent different
> users.
> > Although you cannot run multiple connections to download page
> > resources in a single thread, that's not generally a problem when
> > testing servers, because this tends to average out over multiple
> > users.
> >
> > Just make sure that JMeter generates the required load at the server.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>
Re: simultaneous socket connections per server when downloading components
for a page.
Posted by Felix Frank <ff...@mpexnet.de>.
On 11/02/2010 12:56 PM, sebb wrote:
> On 1 November 2010 21:43, <B....@eventim.de> wrote:
>> Hi Sebb,
>>
>> I am not sure how I can interpret your answer. Is there a other way to simulate this behaviour?
Your question sounds suspiciously like "how can I make Jmeter measure
the time the browser will take to load my page and content"?
There has been a lengthy discussion here on the topic a few weeks ago.
The bottom line is: Jmeter can't and won't do this for you. It's not
worth the hassle trying.
Induce your desired load, and see how your server performs. It's not
Jmeter's job to play browser and report accurate estimates on page
display time.
HTH,
Felix
> No.
>
> JMeter threads each use different connections, as the represent different users.
> Although you cannot run multiple connections to download page
> resources in a single thread, that's not generally a problem when
> testing servers, because this tends to average out over multiple
> users.
>
> Just make sure that JMeter generates the required load at the server.
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
Re: simultaneous socket connections per server when downloading
components for a page.
Posted by sebb <se...@gmail.com>.
On 1 November 2010 21:43, <B....@eventim.de> wrote:
> Hi Sebb,
>
> I am not sure how I can interpret your answer. Is there a other way to simulate this behaviour?
No.
JMeter threads each use different connections, as the represent different users.
Although you cannot run multiple connections to download page
resources in a single thread, that's not generally a problem when
testing servers, because this tends to average out over multiple
users.
Just make sure that JMeter generates the required load at the server.
> Thanks
> Bjoern
>
>
>
>
>
> -----Ursprüngliche Nachricht-----
> Von: sebb [mailto:sebbaz@gmail.com]
> Gesendet: Montag, 1. November 2010 11:29
> An: JMeter Users List
> Betreff: Re: simultaneous socket connections per server when downloading components for a page.
>
> On 31 October 2010 22:25, <B....@eventim.de> wrote:
>> Hi@all,
>>
>> My goal is to design a http load test in jmeter with a real life scenario. In this scenario it is necessary to simulate also the behaviour of the actual browsers. During my tests, I saw that jmeter use always only one tcp connection for each thread to download a webpage, but actual browser like Firefox use up to 8 tcp connections to download a web-page.
>>
>> Is there a way to open more then one tcp connection in jmeter?
>
> No, not for a single thread.
>
>>
>>
>> Thanks a lot
>> bjoern
>>
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>
> ---------------------------------------------------------------------
> 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
Re: simultaneous socket connections per server when downloading
components for a page.
Posted by Deepak Goel <de...@gmail.com>.
Hey
Namaskara~Nalama~Guten Tag
I think the browser might be opening more tcp connections for Gif's. What
you can probably do is have these http request for Gif's as a transaction in
a different thread.
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 3:13 AM, <B....@eventim.de> wrote:
> Hi Sebb,
>
> I am not sure how I can interpret your answer. Is there a other way to
> simulate this behaviour?
>
> Thanks
> Bjoern
>
>
>
>
>
> -----Ursprüngliche Nachricht-----
> Von: sebb [mailto:sebbaz@gmail.com]
> Gesendet: Montag, 1. November 2010 11:29
> An: JMeter Users List
> Betreff: Re: simultaneous socket connections per server when downloading
> components for a page.
>
> On 31 October 2010 22:25, <B....@eventim.de> wrote:
> > Hi@all,
> >
> > My goal is to design a http load test in jmeter with a real life
> scenario. In this scenario it is necessary to simulate also the behaviour of
> the actual browsers. During my tests, I saw that jmeter use always only one
> tcp connection for each thread to download a webpage, but actual browser
> like Firefox use up to 8 tcp connections to download a web-page.
> >
> > Is there a way to open more then one tcp connection in jmeter?
>
> No, not for a single thread.
>
> >
> >
> > Thanks a lot
> > bjoern
> >
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > 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
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jmeter-user-help@jakarta.apache.org
>
>
AW: simultaneous socket connections per server when downloading components for a page.
Posted by B....@eventim.de.
Hi Sebb,
I am not sure how I can interpret your answer. Is there a other way to simulate this behaviour?
Thanks
Bjoern
-----Ursprüngliche Nachricht-----
Von: sebb [mailto:sebbaz@gmail.com]
Gesendet: Montag, 1. November 2010 11:29
An: JMeter Users List
Betreff: Re: simultaneous socket connections per server when downloading components for a page.
On 31 October 2010 22:25, <B....@eventim.de> wrote:
> Hi@all,
>
> My goal is to design a http load test in jmeter with a real life scenario. In this scenario it is necessary to simulate also the behaviour of the actual browsers. During my tests, I saw that jmeter use always only one tcp connection for each thread to download a webpage, but actual browser like Firefox use up to 8 tcp connections to download a web-page.
>
> Is there a way to open more then one tcp connection in jmeter?
No, not for a single thread.
>
>
> Thanks a lot
> bjoern
>
>
>
>
>
>
> ---------------------------------------------------------------------
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: jmeter-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jmeter-user-help@jakarta.apache.org