It's the difference between measuring wind speed with an anemometer and your wet finger in the air.
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 > <[email protected]<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 <[email protected]> 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 <[email protected] > > > >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 <[email protected]> > > 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
