#2: How to Turbocharge Your ASP.NET Core Web Application for Superior Speed
This content details the optimization journey of a Device status dashboard, starting with a 10-25 second load time, addressed first by implementing caching and then further improved with background processing.
We found after releasing a Device status dashboard that the page takes 10-25 seconds on average to load time.
In the next release we added Cache to resolve it with some known issues.
And in the final release we added background processing in order to fix all the known issues.
In this part, I will share you a story of the caching part in more detail.
The decision
So, after the first release, the dashboard has been visited by around 5 people 3 times on an average. So, if we optimize the performance to less than 1 sec, we are saving 5 x 3 x 10 = 150 seconds a day and 150 x 20 days = 50 minutes of productivity which is a very small number to be honest for investing into complex performance optimization solution.
But the product owner still wanted to invest into solving this because once we have a solution to this problem, it can be repeated into the other areas on the web application.
What to optimize?
This is the first question to answer as a developer when you are optimizing the performance. Without knowing what is the root cause or what component/part of the dashboard is taking the most processing time, you cannot optimize.
Switching the development environment configuration of the external device status api from sandbox to production helped me find the root cause that the device status api is the bottleneck as it takes lots of time to respond to the api request.
How would you optimize the external device status api response time? You cannot.
So, I reported back with the possible solution which involves caching.
The Caching Strategy
After some discussions with the product owner team, I suggested the following caching strategy:
On application start, cache the external device status api data for 30 mins
On user visit, show the dashboard from the cache data (if valid) with the last refresh timestamp and ability for user to click the button and load fresh data
If the user sees data from cache, they will also see the time when it was last update.
If the user refreshes the data, it's cached again for another 30 mins which will help other users to see the fresh data without hitting refresh or waiting for 10 secs or more.
The implementation
ASP.NET Core comes with in-built ability to use in-memory caching, distributed caching and output caching options.
As the name suggests, in-memory caching will store the data in the memory allocated to the web application. This is not suitable for my case as we used multiple docker containers configured to scale up or down the instances of the application using aws ecs. Data stored in the cache of the one of the application instance will not be available to the other instance as it's stored in-memory.
output caching option uses in-memory cache by default and with the ability to manually invalidate/refresh the cache will make it complex implementation.
So, I decided to use distributed caching called Redis as I had previous experience setting up Redis in the development and production environments.
Redis on windows comes with a quick and easy installer along with a tool called another redis manager which will help you review data of the redis cache.
One the production, I initially used a redis server as container but later on switched to AWS Elasticache redis instance as caching became first class citizen in our asp.net core application and was being used in all modules of the application.
Final thoughts
So, finally, I had another release which was having better performance but with two known issues with this solution:
The device status was not real-time and after a while, the cache data is too old.
The user visiting the dashboard first-time will still experience the delayed page load.
Frequently Asked Questions:
What issue did the team identify after releasing the Device status dashboard?
The page took 10-25 seconds on average to load.
How did the team address the performance issue in the next release?
Cache was added to resolve the issue, along with addressing some known issues.
What additional improvement was made in the final release to fix all known issues?
Background processing was added in the final release.
What led the team to invest in performance optimization despite the seemingly small time savings?
The product owner recognized the potential for the solution to be applied to other areas in the web application.
What was the first question addressed when optimizing performance as mentioned by the developer?
What to optimize? (Identifying the root cause or component taking the most processing time.)
How did the developer determine that the external device status API was the bottleneck?
By switching the development environment configuration of the external device status API from sandbox to production.
What was the proposed solution to optimize the external device status API response time?
Caching was suggested as a possible solution.
Describe the caching strategy suggested by the developer.
On application start, cache external device status API data for 30 mins; on user visit, show the dashboard from cache data (if valid) with the last refresh timestamp and the ability for the user to load fresh data by clicking a button.
Why did the developer choose Redis for distributed caching over in-memory caching?
In-memory caching was unsuitable due to the use of multiple Docker containers, and Redis offered a distributed caching solution.
What were the two known issues with the final release's caching solution?
The device status was not real-time, and after a while, the cached data became too old. Additionally, first-time users would still experience delayed page loads.
This article is cross-posted from Facile Technolab Blog. Read the orginal article here.