Performance Testing

From CitconWiki
Revision as of 04:03, 12 September 2015 by Luke.elliot (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search

Testing response times throughout the project lifecycle can help as an early indicator of performance issues.

Production-like environments are expensive to use - this can lead to limited load testing, and the resultant risks.

When benchmarking performance testing, don't change the codebase and the environment/infrastructure at the same time - freeze one whilst modifying the other.

Stress testing - finding where the app breaks. Load testing - testing how the app deals with a typical/estimated load

A degree of performance testing can be done at each CI build cycle, but not always to the degree that will show system-level performance issues.

Some photos of Stuart Moncrieff's Agile Performance Testing slidepack are available here: www.jds.net.au/news/melbourne-citcon-2008/

Problems

  • Often at the end of the release cycle.
  • Scaling environments.
  • Trust level of results.
    • Meet stated performance goals.
    • Stress testing
    • Load testing

Tools

  • JMeter
  • new relic

Strategies

  • Decompose your application stack testing the throughput/load of each component.
  • When testing a load balanced system make sure you have more than one to ensure handoffs. Consider taking one down and bringing it back up.


How do you convince your boss that performance testing is inadequate? If it isn’t going to save them or make them money, they are not likely to alter their strategy.