>> 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]
