This document discusses different types of performance tests including load tests, stress tests, soak/endurance tests, and spike tests. It describes what each test aims to find including bottlenecks, capacity limits, stability, and response times. Key things to test are how the system performs under expected and extreme workloads over time. The environment must be realistic to measure business KPIs. Analyzing test results and tools is important to understand limitations and optimize performance. Performance testing can be one of the most costly test types due to testing at scale and analyzing large result sets.

1. S
Performance Tests
Principles
Author Dariusz Kozon

2. What is performance testing?
S Following Wikipedia:
”
performance testing is in general testing, performed to
determine how a system performs in terms of
responsiveness and stability under a particular
workload. It can also serve to investigate, measure,
validate or verify other quality attributes of the
system, such as scalability, reliability and resource
usage

3. Test vs Testing Envs
Test environment Testing environment
Application server and DB server Testing application (for instance
JMeter)
Application itself Testing computers (and threads)
Network on servers side Network on site testing
infrascructure
Static files services Sniffers (like Fiddler)
Profilers
Test specification and requirements

4. Load Test
S Key questions: Can we get expected load on level XYZ
users in time of DD:HH:MM? How big are standard
response times?
S What we can find there:
S Confirm intended specification are being met
S Check critical scenarios
S Chcekc expected number of users and find ut standard
system behaviour under estimated load
S Find out response times and compare with requirements
andor market andor techincal standards
S Find out bottlenecks in application and DB Servers

5. Stress Test
S Key questions: How is system’s robustness under
extreme load? How system fails?
S What we can find there:
S Find out upper capacity of load (for application and DB)
S Find out system stability and breaking points
S Find out safe usage limit (f.eg. point for finding
additional resources in cloud)

6. Soak / Endurance tests
S Key question: How system will perform after couple
hours / days / weeks / longer period of time?
S What we can find there:
S Memory leaks
S DB Cache warming up
S Decrease response times under rising time of execution
load

7. Spike tests
S Key question: How system fails and restore itself?
S What we can find:
S Behaviour after extreme load in short time

8. Other various scenarios
S Testing and find proper configuration of environment
S Scalability tests
S Big number of low users
S Low number of heavy users
S …

9. Remember
S It would be great if tests are:
S Realistic (to business KPI)
S Scalable and parameterized
S HTTP/S testing != front end rendering time

10. Possible bottlenecks
Test environment Testing environment
Memory and CPU usage on APP
server
Memory and CPU usage on
computer
Memory and CPU usage on BD
server
Possible threads to use on
computer
Network Network
Simulating testing from other geo
loactions

11. Load balancer
S For wide picture we need to remember:
S First test particular nodes of server
S Next when particular nodes are OK, test entire
environment using Load balancer
S Test some configurations of load balancer to find best
one (especially in case of different resources on nodes)

12. Do we need cache? <tricky>
S Answer is Yes. Why?
S On production cache will be turn on
S Don’t forget about queries which are the same and don’t change
in time of work.
S Part of the performance tests should be time when cache is
warming up.
S Why this question is valid? Why anyone would switch this off?
S Test data are very crucial from perspective of cache
S More test data = more reliable tests
S There could be situation when you are testing cache instead of real DB

13. Analyse
S What we need to analyse performance results:
S Results from performance tool
S Results from profiler on side of server (execution of
particular methods)
S Status of CPU and Memory usage in time on db and app
servers
S Know bottlenecks
S Know what we exactly tested (load balancer, entire server?
nodes?, exclude bottlenecks)

14. Tools

15. How much it cost?
S It always depends but according to environment (and
scale to real production environment), how system is big
and how much time it will get, time spent on analyse of
results – it preety always one of the most coslty types of
tests accross projects.

16. Thanks for attending!
S If you have any questions feel free to ask me
S dariusz@kozon.net
S or d.kozon@kainos.com