>> 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. > > What do you usually test with Jmeter? If it's not response time, then what > is it you test?
I don't really see how the above quote is pertinent to you question. At this time, I do not rely on the timings as reported by Jmeter, but exploint reverse proxy logs instead. Jmeter's role is to induce load and that's it. > If it is a response time, then how do go around the fact that browser sucks > resources on several connections when as Jmeter thread works on a single > connection? I don't see how I could do this at this time. Keep in mind that there are three very different load times we could be discussing: 1. The total time Jmeter takes to load everything 2. The total time your browser takes to load everything 3. The time your browser takes until you can see anything, at least some text All are usually different. For me, the last one is the most interesting, and it is very close to the time to load the HTML content and nothing else. As such, even though I make it a point to load everything, I don't really have a use for time #1, which Jmeter reports to me. An easy workaround could be an additional thread group with few threads, that does *not* load embedded content and thus reports HTML load time at the load dictated by the "main thread group" that does load all content. But I'm sure others will disagree about almost all of this ;-) Still, do keep in mind that time #2 is not all that important, don't waste your energy on figuring out a way to measure it with Jmeter (it may not even be possible). Cheers, Felix --------------------------------------------------------------------- To unsubscribe, e-mail: jmeter-user-unsubscr...@jakarta.apache.org For additional commands, e-mail: jmeter-user-h...@jakarta.apache.org
