I notice you didnt actually say whats the difference between two browsers and one.
In any case web test tools have always been in two categories Those that drive the http request/response (JMeter, Grinder,older versions of load runner) and those that drive the browser (selenium, watir, qtp, newer versions of load runner). Do you seriously think that people who develop and/or use the first category are measuring wind speed with a wet finger or is it more likely you dont get what you need to do if you want to use one of these tools to still get "true" response times? On Wed, Feb 6, 2013 at 7:13 PM, Zippy Zeppoli <[email protected]>wrote: > 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 >
