>I politely disagree. Disagreement is good. I might learn something :) >Those were (I believe) referenced using <img> elements Well yes if you have dynamic images (e.g. server side generated graphs) but Id normally make this a separate request (because the success/failure should be distinct than the success/failure of the containing page). As well as validation would consist of something more than request returned 200.
>I prefer to take into account the potential overhead of embedded content But you dont come to know this at least when you are talking about response times. All you get is a single figure right? Also if something like "Connection: close" headers are signficant for your application then why would you request resources in a single thread whereas a browser will open multiple sockets in parallel? regards deepak On Tue, Sep 14, 2010 at 11:53 PM, Felix Frank <[email protected]> wrote: > > So if accurate response times are needed , I cant use this feature and if > > accurate response times are not needed then I dont need this feature > anyway. > > I politely disagree. > > I once load tested an application which used some background PHP scripts > for statistics purposes. Those were (I believe) referenced using <img> > elements. Jmeter's ability to request those pseudo-images was very > useful here, because you absolutely want to run those scripts during > your load test. > In most cases, I prefer to take into account the potential overhead of > embedded content, in whatever way it may manifest (e.g., some load > balanced setups require "Connection: close" headers, so there's some > overhead for opening new connections for each piece of static content > etc. etc.) > > But then, there certainly are drawbacks and care must be taken when > considering the results that Jmeter reports. And I'm not proposing that > one should always and at any cost use this setting. But it certainly > does have plentiful uses. > > Cheers, > Felix > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
