From the Open Source Load Testing presentation http://www.slideshare.net/richardfriedman/open-source-load-testing

Having run and worked with many teams on load testing, a pattern in the process of load testing emerges.  It is not complex, and if done right the act of load testing becomes transparent to the process of resolving performance issues.

  • Define Requirements. As discussed in common sense of load testing, having requirements simplifies the complexity and allows you to stop load testing at a reasonable project point.
  • Record or Create.  Load testing tools such as Apache JMeter provider the ability to record from the browser through a proxy.  BlazeMeter also provides a Chrome extension to record JMeter tests (which can run via RedLine13).  The group of load testing tools provide their own underlying languages and definitions for creating load tests.
  • Play Load Test.  Your first run will be to simulate a single user from your own machine to see if the test plan executes as expected.
  • Scale on Single Server.  Next reaction, how much load can your desktop generate.  Perhaps you only need a 50 user simulation, something most modern hardware could handle.   Typically you will keep scaling load from your own machine, no need to test bigger if your ‘black box’ can not handle that load.
  • Run at scale.  Now we are ready to take our load test and simulate – hundreds, thousands, millions of users.   This can not be achieved on your local machine.  This is where services such as Redline13.com help.
  • Build Test Environment.  A bit overlooked in the process, and happens in parallel, but where is your blackbox?  Is this production or do you need to have a production mirror.   This is a complicated step and slows down load testing efforts dramatically.  There is no right or easy answer.  AWS and Azure make this easier to achieve today, but it is never as easy as it looks.  Many folks load test on production environments.
  • Analyze.  This is the hard work.  We have results and we can either ‘Pass’ or ‘Fail’ according to the requirements.
    • Fail.  This means we need to fix code, change system configuration, or perhaps scratch our head until we find the bottleneck
    • Pass.  We are rewarded for our hard work and can move the project forward.

 

OSLT_BuildRunIt

 

 

Comments are closed.