With this posting I want to start a series of small articles which deal with performance tests and performance tests in projects with CQ5. It can be applied to many other web projects.
This topic is one of my all-time favorites in a project plan. According to my experience with CQ projects in the last yearsperformance tests are usually planned to be executed 3 weeks before the golive, with some person days of preparation planned. Noone knows, what should be tested to what extent, and also noone knows what the results should be. And performance tests are also one the first activities removed from the project plan if time is getting short.
But of course most members (mostly the technical ones) of the project team know, that dropping the performance tests will cause heavy problems later in production. But the “told you so” afterwards isn’t really helpful …
Some reasons, why you should do a performance test:
- During development the focus is on coding and functionality. Functional tests are executed by developers or small test teams. In a production use case the number of users is usually much higher. Just working on the assumption, that the system works properly, is highly risky.
- When you have done a performance test, you should know some conditions, under which the system performs well or fails. In both cases you learn about your system and you can either address deficits early or reduce the risk of performance assumptions.
- Operation will have an easier job, if you can tell them about the capabilities or limits of the system. Then they can act accordingly in case of problems and don’t need to waste effort to determine root causes and issues of your shiny new application. (In the end they cannot do much about it, especially on a production system. They need to bring it back online as soon as possible, they won’t debug it.)
- Performance deficits sometimes go hand in hand with stability issues. Consider a request, which requires some memory to execute. If you have 5 of such requests in parallel, it is not a problem, but in case you have 100 concurrently of them (due to the slow processing of them), the stability of your JVM might be impacted.
- The business aspect: A bad performance can slow down your business performance and have a huge impact on your KPIs like successful conversions. If you know, that certain parts of your site are slow, you can address these deficits early in the project, long before they impact the KPIs.
So from a risk-perspective it is very helpful to conduct performance tests. If the discussion is about cutting a feature or a performance test, strongly recommend the feature (unless it’s one if the features of the minimum-viable product). From an overall stress-level it is usually much easier to add a feature after golive than to have a release, which has performance and/or stability problems.