There is a default, not doing it, the feature request is the ability to change that default within a larger scope.
I'm not trying to debate the merits of hosting images on separate servers. In the application I'm currently testing, no matter how much traffic it ever gets the images won't be hosted on another server because the product vendor isn't going to do that. I'm just trying to point out that in the two applications I'm currently testing, having such a feature would be nice. And, as far as I can tell, there isn't any technical reason not to do it. Peter Lin wrote: > to my knowledge, there isn't a default. I would advise against making > all the HTTP sampler get the embedded resource. I mainly work on > large sites and performance is usually a hard requirement. The > applications that I've worked on first hand used a dedicated image > server. In fact, if you look at any website that supports moderate to > heavy load, all the images are served off a dedicated image server. > > hosting the images on a dedicated server will easily improve the > performance of a website by 2-3x depending on how many images each > page has. the more images a page has, the greater the performance > improvement. > > hope that helps > > peter > > > On 5/25/05, Chad La Joie <[EMAIL PROTECTED]> wrote: > >>Yep, I saw the check box, and I do check it. My thinking was that >>instead of having to check that box for each request (and we have a fair >>number of them in our test plans) it would be nice if I could have that >>be the default behavior, either because it was the default behavior for >>the HTTP sampler, or because I was able to set on the HTTP request defaults. >> >>Peter Lin wrote: >> >>>http://jakarta.apache.org/jmeter/usermanual/component_reference.html#HTTP_Request >>> >>>if you look at the Http request, you should see "retrieve all embedded >>>resource". if you check that, Jmeter will retrieve all the images. >>>Keep in mind that most users are not going to download all the images >>>on every single page. Any image that has already been downloaded and >>>cached in the browser won't be re-downloaded. the exception to this >>>case is when a user explicitly sets the browser to always retrieve >>>every image. >>> >>>I'm assuming there's access logs from production. What I tend to do is >>>look at the log report and figure out the ratio of images to pages. >>>this way, you get closer to simulating real traffic conditions. >>> >>>peter >>> >>>On 5/25/05, Chad La Joie <[EMAIL PROTECTED]> wrote: >>> >>> >>>>When load testing web applications you generally want to simulate, as >>>>closely as possible, what would happen if a real user was doing their >>>>thing. So, for us, that means that for each HTTP request we want it to >>>>retrieve all the resources for that page as well. It seems like this >>>>might be a very common thing, perhaps even the normal behavior people >>>>wanted. So I was wondering if either the default behavior of the HTTP >>>>Request sampler could be to fetch those things, or in a more >>>>configurable manner, if there could be an option of the Http Request >>>>Defaults config element to set this. >>>> >>>>Just a thought. >>>>-- >>>>Chad La Joie 315Q St. Mary's Hall >>>>Project Sentinel 202.687.0124 >>>> >>>>--------------------------------------------------------------------- >>>>To unsubscribe, e-mail: [EMAIL PROTECTED] >>>>For additional commands, e-mail: [EMAIL PROTECTED] >>>> >>>> >>> >>> >>>--------------------------------------------------------------------- >>>To unsubscribe, e-mail: [EMAIL PROTECTED] >>>For additional commands, e-mail: [EMAIL PROTECTED] >>> >> >>-- >>Chad La Joie 315Q St. Mary's Hall >>Project Sentinel 202.687.0124 >> >>--------------------------------------------------------------------- >>To unsubscribe, e-mail: [EMAIL PROTECTED] >>For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > -- Chad La Joie 315Q St. Mary's Hall Project Sentinel 202.687.0124 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
