So I guess here is where we agree to disagree. However > I don't really care for the response code. Correctness is almost always a prerequisite for a performance test. But yes , to each, his own !
On Thu, Sep 16, 2010 at 12:30 AM, Felix Frank <[email protected]> wrote: > >> 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. > > The point is, I want Jmeter to do the requests, and I cannot be bothered > manually adding appropriate Samplers for all of them. I don't really > care for the response code. > > Of course, it is of help to me that I can rely on logs from my reverse > proxy to gauge response times, response codes etc., so I don't have to > spend much thought on what Jmeter will make of the different responses. > I can see how this can be a very important point for other people (you, > for instance). > > >> 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? > > Because I don't want to neglect that content, especially when the > applications I test are not of my own making. I cannot know then what > content is important load-wise and which elements might not be. > > Addings Samplers for the embedded content I want is not only > impractical, it also not feasible wrt. the Lean&Mean principle. I've > found this principle to be of the essence, as larger numbers of threads > have been known to run my Jmeter servers out of memory when being > generous with the number of Test Plan elements. > > I feel like I'm preaching again already. Sorry :-) > Of course, none of these opinions can be expected to apply to all use > cases, so I urge all readers to make up their own minds. > > Thanks, cheers > Felix > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
