jmeter-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Zippy Zeppoli <zippyzepp...@gmail.com>
Subject Re: complex javascript actions in jmeter load test
Date Thu, 07 Feb 2013 03:20:02 GMT
Check out keynote or gomezs explanation on their load test tools. Perhaps
it will make sense then. Synthetic load tests have their purpose and jmeter
is a good tool for that.

Bringing this back to my original point of jmeter as a tool rather than a
philosophical discussion about load testing:

It won't perform complex interactions with a web application however or
perform complicated flows and aggregate metrics on the cumulative
transaction. It works at layer 7 HTTP layer only. you could probably cock
around with logic controllers and beanshells and other sorts of nightmarish
adapters, but in this case you should realize jmeter is mot the tool for
the job. Browser presents a more comprehensive tool of real performance
with such applications. Browsers also won't issue requests at the rate a
tool like jmeter will, skewing your viewpoint of how your web app truly
performs.

Not debating this any further, you may do what you wish but if you think
jmeter is a comprehensive tool for measuring web application performance I
feel sorry for your users.

Fin

On Wednesday, February 6, 2013, Deepak Shetty wrote:

> >I think you may be  missing the point.
> Heh - the feelings mutual
> >There is no DOM rendering happening...and it won't reflect the true
> response time
> If you need browser times , yes Jmeter cant help you directly.
>
> But browser render times are really irrelevant to a *load test*. Lets say
> using any tool you have loaded the server with some high load . Now Lets
> say you and I (assume the addition of two requests makes no difference to
> the server). access this via a browser with similar conditions(same
> browser, network, cpu, memory etc). Is there any difference that you and I
> will see? Do you really need two or many browsers to figure out how much
> time your DOM rendering is taking or will one browser suffice?(lets ignore
> that you still arent getting "true" times - because browser times are
> dependent on what else the user is doing, what sort of network bandwidth he
> has , what browser he is using, what are IE cache settings are and so on).
>
> Pre - cloud , it was prohibitive to drive browsers to do load tests - now
> it is possible , but the amount of additional value that you get over a
> http request/response load test and some browser analysis is minimal to
> none. (Some types of scripts are easier to write with a browser driven tool
> though).
>
>
>
>
>
>
>
>
>
> On Wed, Feb 6, 2013 at 4:30 PM, Zippy Zeppoli <zippyzeppoli@gmail.com<javascript:;>
> >wrote:
>
> > I think you may be  missing the point.
> > Real load cannot be tested via HTTP interactions.
> > There is no DOM rendering happening.
> > I can make HTTP requests all day and it won't reflect the true response
> > time unless it's done through a browser.
> >
> > Recording a script in Jmeter proxy is trivial. Simulating *real* user
> load
> > is not it requires a browser and interactions with a web application.
> >
> > On Tue, Feb 5, 2013 at 6:51 PM, Deepak Shetty <shettyd@gmail.com> wrote:
> >
> > > >Actually that does matter it cannot do JavaScript. If a request
> requires
> > > >you need to be able to click a JavaScript button then the request will
> > > >never happen.
> > > The point is that what happens when the button is clicked? Assuming
> its a
> > > server - ajax call then A HTTP call is made and some parameters are
> > passed
> > > and some values are returned. Thats whats important for the load test ,
> > not
> > > the fact that javascript was executed.
> > > So when you record the script , you will be the person clicking the
> > > button(you are recording your actions) , JMeter will record every
> > > interaction that makes a call to the server and will record this as a
> > > separate HTTP request and when you run the script the same request will
> > be
> > > made as if someone clicked the button!
> > >
> > > You dont need to use the recorder either , you can modify the script
> > > yourself.
> > >
> > > If the javascript didnt actually make any server side call - then it
> > doesnt
> > > matter because you dont want to load test this anyway.
> > >
> > > Have you actually tried this? It sounds as if you have a problem
> > recording
> > > your script and you probably have concluded that JMeter doesnt do
> > > javascript (true) and hence cant test websites that do javascript/ajax
> > > (false)
> > >
> > > >Real browser is needed
> > > Not for a good deal of use cases - as many of the people on this
> mailing
> > > list can attest too.
> > >
> > >
> > >
> > >
> > >
> > > On Tue, Feb 5, 2013 at 6:44 PM, Zippy Zeppoli <zippyzeppoli@gmail.com
> > > >wrote:
> > >
> > > > Deepak,
> > > > Actually that does matter it cannot do JavaScript. If a request
> > requires
> > > > you need to be able to click a JavaScript button then the request
> will
> > > > never happen. No request will ever be made.  Also testing true web
> > > > performance requires rendering the DOM, not just initiating HTTP
> > requests
> > > > and recording the response time, rps, etc.
> > > >
> > > > Real browser is needed, with JavaScript, and Jmeter doesn't integrate
> > > well
> > > > with this, it isn't designed for this, which is understandable. The
> > > problem
> > > > is there is a gap between real browser testing (owned by third party
> > > > companies) and open source tools (Jmeter). There's nothing in between
> > for
> > > > real-browser based performance testing. I could go into why, but its
> > off
> > > > topic of this list, and I'd rather spare everyone the gas.
> > > >
> > > > Point being, Jmeter cannot solve my problem, without some serious
> > > > customization.
> > > >
> > > >
> > > >
> > > > On Tue, Feb 5, 2013 at 6:33 PM, Deepak Shetty <shettyd@gmail.com>
> > wrote:
> > > >
> > > > > Hi
> > > > > You are getting too caught up in the JMeter doesnt do javascript
> > thing.
> > > > In
> > > > > most cases it doesnt matter.
> > > > > You have a webserver that is receiving HTTP requests - whether
> those
> > > > > requests are generated via the user clicking a link or via AJAX or
> > via
> > > > > flash is hardly relevant to the webserver. It sees HTTP requests
> and
> > > > sends
> > > > > HTTP responses.
> > > > > JMeter deals with HTTP request and responses. As long as you can
> make
> > > the
> > > > > same request that your javascript is making (which you can see via
> > the
> > > > > record

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