In our previous blog post we saw why calling functions in Angular template expressions is bad practice and can have huge performance impact on your application.
Now it's time to take a look at Angular ChangeDetectionStrategy and see how it can help us improve the performances of our Angular applications.
At OctoPerf we created a load testing web application using Angular for the frontend.
The application features IDE capabilities (like IntelliJ Idea or VSCode) to create load testing scripts:
We faced several performance issues while creating such a complex web application. This blog post is the first of a series dedicated to common Angular performance issues and how to solve them.
This article is the last in a series of overviews of our new UI. You can find the others here:
This time we will dive into the changes we've made in the analysis.
The analysis page has remained mostly the same:
In this blog post we are going to look at some of the uncommon performance tests. By this we mean those scenarios that are not what we believe are commonly executed but those that are run periodically at best.
These uncommon scenarios should not necessarily take priority over the more common performance scenarios. They do add value by stressing parts of your application under test that may be missed by the more conventional tests.
We will discuss each scenario in turn and look at the benefits and some of the difficulties you may experience in designing these scenarios. We will also take time to give examples of when these scenarios would be useful.
We have spoken in a previous blog post about documentation about how we believe that if you are building performance tests that support either Continuous Integration or Continuous Delivery then having to produce performance testing documentation before and after each test does not fit with this methodology.
This got us to thinking that if we truly want to use an agile framework and continually push code to production then we need to also consider how we monitor and report on our performance test results produced from our testing tools.
If you have an agile testing process, then you will have functional tests built into this deployment process that run in each environment and if you have a mature robust process then this process deploys to production with no manual intervention if all the functional tests have passed along with any deployment checks.
Now in reality we need to have a performance testing stage in this process as well as each release needs to go through a performance test, whether that is a full suite of peak volume, soak test, scalability tests scenarios or whether that is a regression tests of core functionality.
And this is the bit that we are going to discuss in this blog post because if your organisation wants to push code directly to production then you do not have the luxury of running your performance test, analysing the results and writing up a report to be signed off.