Interesting discussion, I must jump in! My thoughts on application load testing: 0. Keeping in mind that my load test will never reveal all performance issues. 1. Building a load test scenario which reflect the real life scenario, as close as possible. Usually with access log analysis of the current productive system. 2. Always skip the static resources loading, but if you do, use cache config element (but make sure you understand how it works and what the diff between its behavior and browsers' behavior) 3. No matter how much effort you put into researching and building up a real life reflecting load test scenario, you will always miss at least one very important performance issue, which will bring the new system down after the very few hours/days of the launch. 4. Understand that the performance of the application is not just during load testing but also after the system is alive (and prepare yourself for performance analysis of the productive system when problems occur). 5. I recently heard that new approach of trying to overkill/break every component in the system on a regular basis, so developers will need to improve all the time. I don't really like that approach as it causing a lot of noise and panic (you gonna be called the boy who cried wolf). Instead I prefer to run such tests but keep results for myself, or document, but leave them for later times, when no other more important performance topics need to be addressed. The more important topics are the ones which you believe that will happen during real life usage of the system under expected loads. 6. Don't stop load testing after the system release/launch. Keep this to be part of your process and continue to perform load tests with every new release or on a regular basis. Don't throw away your load testing scripts or leave them un-maintained until the are forgotten and not relevant. Try to re-adjust your load tests with an up-to-date usage patterns from the productive system on a regular basis and add new samplers to reflect that if needed. Adjust the scripts to test new features.
Shmuel Krakower. www.Beatsoo.org - re-use your jmeter scripts for application performance monitoring from worldwide locations for free. On Fri, Feb 22, 2013 at 4:58 PM, Robin D. Wilson <[email protected]> wrote: > There are different reasons to to either way. As Flavio pointed out, if > you only want to test the main framework of your site, you would exclude > everything except the main page. If you want to simulate a real user, you > would include each embedded resource once per user (under the assumption > that your users will cache those embedded files in their browser once they > fetch the the first time. If you want to exercise your web server, you > would get all files every time. > > In our setup we configured our test scripts to only fetch the main page. > Then we have a Request Defaults control that allows us to enable Request > All Embedded Resources when we want to add load to the web servers. > > Our setup has web servers that handle the static files (.js, .css, images, > movies, etc.), but that proxy to our application servers for the framework > of our pages. So with our scripts setup the way they are we can easily > exercise both the application servers (by disabling the Request All > Embedded Resources), or the web servers (by enabling it). > > Also, I personally don't hold much stock in the 'test it like a real user > would use it' methodology, because I've found that I can find quite a bit > more defects and issues with the targeted testing of specific subsystems. > For example, when we test so that we add in the embedded resources, we > almost never generate enough load on the application servers to find a > problem (especially problems with load/performance). That's because the > data download for the embedded files swamps our 30GB test LAN and the > bottleneck becomes file IO (our stuff is heavily multimedia). But by > leaving out the embedded resources, we can drive enough load on the > application servers to see things like poorly constructed DB queries, and > code level performance issues. > > My goal in testing is always to find the most bugs in the shortest amount > of time as possible. I've found that stripping each subsystem down and > hitting it as directly as possible generally yields more bugs per hour of > testing than trying to do a wholistic test, and it has the benefit of being > easier to maintain the test scripts/procedures as well... > > -- > Robin D. Wilson > VOICE: 512-777-1861 > > > > On Feb 22, 2013, at 7:02 AM, Flavio Cysne <[email protected]> wrote: > > Depends on what are you trying to achieve with the test. > > I usually exclude only favicon.ico requests. If you are trying to test only > the main requests, exclude everything that doesn't matter. If you are > trying to simulate an user navigating the site/application do not exclude > anything, unless you check "Retrieve embedded resources". > > > 2013/2/22 Amit Kumar <[email protected]> > > > Dear All: > > > > Hope you all are doing great !! > > > > I have a query. After recording the using Proxy Server, it records many > > files like .jpg, .css, .js. ect. So my question is which files can I > > exclude while recording? > > Or which files can I delete after recording? > > > > > > Thanks in advance !! > > > > - > > Thanks and Regards, > > Amit > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
