Skip to main content

Posts

Showing posts from October, 2015

Performance Testing is Easy

Performance testing is easy. We just throw as many requests at the system as we can as quickly as we want and measure the result. Job done right? tl;dr? Short form... Understand the user scenarios and define tests. Review the mix of scenarios per test and the type of tests to be executed (peak, stress, soak, flood). Size and prepare the test environment and data. Consider the location of injectors and servers and mock peripheral services and systems where necessary. Test the tests! Execute and monitor everything. Start small and ramp up. Analyse results, tune, rinse and repeat until happy. Report the results. And question to what level of depth performance testing is really required... Assuming we've got the tools and the environments, the  execution of performance tests should be fairly simple. The first hurdle though is in preparing for testing. User Scenarios and Test Definitions In order to test we first need to understand the sort of user scenarios that we're

Availability SLAs

I've been considering availability recently given the need to support five 9's availability (amongst other non-functionals) and have decided to draw up the list below. Thoughts/comments appreciated. Assumptions at the bottom. 99% - Accepted downtime = 3.6 days/year Single server is sufficient assuming disk failures and restarts can be accommodated within minutes to hours. Data centre (DC) failure means we've time to rebuild the application elsewhere if we need to (most DC issues will be resolved quicker than this) and restores from back-up tapes should be easy enough. Daily backups off-site required in case of total DC failure. 99.9% - Accepted downtime = Just under 9 hrs/year We probably lose 4.5hrs/year due to patching if we use a single server which only allows 4.5hrs to resolve a crash or other failure. This is close and likely not enough time (especially if a crash occurs more than once a year). Therefore we need a clustered service for resiliency (alternating which no