Thank you very much all of you for your valuable suggestions and help !! It is really helpful for the starter like me.
On Tue, Feb 26, 2013 at 4:15 AM, Shmuel Krakower <[email protected]> wrote: > 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] > > > > > -- Thanks and Regards, Amit
