> Depending on server application some resources maybe generated >and come cacheable. If this is significant for your application then you must also simulate the way the browser requests resources and the number of requests it makes in parallel. Also it depends on what your goal is. If it is whats the response time under load you are better off calculating the static resource times on a browser and adding it with safety margins to your Jmeter results (which have static excluded).
>So you shouldn't just disable resources load. I'd say this is my rule of thumb. I disable it unless I know of some reason not too. Generated images do not fall under this category- i'm assuming the original poster meant static css/js/images. Usually sites with high performance requirements have a separate CDN so the static resource load does not affect the page load. regards deepak 2010/6/29 Andrey Pohilko <[email protected]> > I disagree. Depending on server application some resources maybe generated > and come cacheable. So you shouldn't just disable resources load. > > JMeter HAS item to simulate browser's cache behavior. It's Cache Manager. > > С уважением, > Андрей Похилько > > -----Original Message----- > From: Bhattacharya, Sudip [mailto:[email protected]] > Sent: Tuesday, June 29, 2010 7:36 PM > To: JMeter Users List > Subject: RE: Is it good practice to exclude common page items during > record? > > Yes, as Felix mentioned, it is good practice. > > Idea is static content would be cached by browsers generally, so would be > downloaded only once. If you run them thru JMeter (without caching > enabled), > JMeter would fetch them every time overloading the network. This is not a > normal use case scenario, so it's better to remove static content like > images, css, java script, etc from your samplers. > > > > ______________________________ > Sudip Kumar Bhattacharya, PMP > Senior Principal Consultant, BPM Track, Products Org > Genpact, Delhi, India > > C +91 98995 16992 > > E [email protected] > www.genpact.com > > -----Original Message----- > From: Felix Frank [mailto:[email protected]] > Sent: Friday, June 25, 2010 5:01 PM > To: JMeter Users List > Subject: Re: Is it good practise to exclude common page items during > record? > > Generally, it is good practice. Probably, the checkbox "retrieve > embedded contents" in the HTTP sampler will do what you want. Only keep > recorded samplers for actual HTTP content (be it php, aspx or whatever) > and have Jmeter deal with the images. > > Also refer to > http://jakarta.apache.org/jmeter/usermanual/best-practices.html#lean_mean > > Cheers, > > Felix > > On 06/25/2010 01:26 PM, Spudona wrote: > > > > I'm not sure if I should exclude image files during recording. It > certainly > > makes the recorded test shorter and easier to edit if necessary but does > > this mean that the images on each page aren't part of the load test and > if > > not, what is the reason to exclude any content from a load test? > > > > Andrew > > -- > MPeX.net GmbH / Werner-VoЯ-Damm 62 / D-12101 Berlin / Germany > MPeXnetworks / www.mpexnetworks.de > Tel: ++49-30-78097 180 / Fax: ++49-30-78097 181 > > Sitz, Registergericht: Berlin, Amtsgericht Charlottenburg, HRB 76688 > Geschдftsfьhrer: Lars Brдuer, Gregor Lawatscheck > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > This e-mail (and any attachments), is confidential and may be privileged. > It > may be read, copied and used only > by intended recipients. Unauthorized access to this e-mail (or attachments) > and disclosure or copying of its > contents or any action taken in reliance on it is unlawful. Unintended > recipients must notify the sender immediately > by e-mail/phone & delete it from their system without making any copies or > disclosing it to a third person. > > > > --------------------------------------------------------------------- > 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] > >
