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

Slide #1 Common Sense of Load Testing

You will notice the presentation does not start with ‘Why we need or What is load testing?”. In this day and age we have had too many public examples of sites, products, and APIs falling down because of scaling issues. Every day you can still find an article to point out – Thou Shalt Load Test. We make the assumption you are reading this because you already know that, but want some insights into what is common sense in load testing.

  • Everyone expects it to scale!   A product owner does not hand over a specification assuming it will be built to support only one user at a time or only 1 concurrent transaction. Right or wrong, there is an inherent expectation that development and QA will produce a product that scales. Your job is to always ask and review what is the requirement and expectations for performance.  Knowing or asking this will cure future issues in your development process.
  • Always run a load test.  Launching a new product and just tested internally or on your dev and QA environments is not enough.  You don’t need to be elaborate, just build and run one load test.   The whole process for a web application or even mobile app calling APIs can take as little as 15 minutes.  This will give you some level of confidence you can start to support multiple users on the system.
  • Start Simple.  Your first load test plan does not have to model every user interaction, as you get comfortable building load test plans this will become easier and easier.  A small win will give you confidence that is easy to spin up load tests.
  • Model User Behavior.  Once you get comfortable, build or record a test plan modeled on user behavior.   A load tests that hammers a single API call can have value for stress testing, but might not really help you make a better product that meets the users requirements.
  • Set realistic goals. If your goal is to make it fast or support a lot of users, you need to be a bit more definitive.   Goals should be in a time range – 250-300 ms for an api call, or support 1,000 transactions/second when thinking about throughput.  Also keep your goals right-sized, setting goals too high might burn development time on something that is not a user requirement.
  • Load Tests expose issues, they don’t fix them.  The creation and execution of a load test should be seamless.  The load test itself should fade into the background, your responsibility is to expose performance issues.  Then you can diagnose and resolve these issues.   Resolving performance issues should be the hard work, starting a load test should be painless.

Have more common sense of load testing ideas?  Send them to info@redline13.com.

Comments are closed.