#2: How to Turbocharge Your ASP.NET Core Web Application for Superior Speed

#FacileWeekly 20

Hello?? and welcome to Facile Weekly . I'm your host?Prashant Lakhlani .

In the previous week's article , a story about how I optimized a sluggish device status dashboard taking 10-25 seconds on average to load the content to load in real time.

This is a follow up article that contains a little more details about the caching and background job strategies.

#2: How to Turbocharge Your ASP.NET Core Web Application for Superior Speed

So here is a quick recap of previous week's article .

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.

Next week, I will cover how I used background processing to solve these two known issues and how we ensure users are always seeing fresh data without waiting.

See you next week.

Related Articles

• Redis with .NET
• Distributed caching in ASP.NET Core
• Redis Best Practices

About Us

???????????? ?????????????????? ???? ?? ?????? ?????????? .?????? ???????? ?????????????? ?????????????? ?????? ?????????? ???????? ?????????????????? ???? ?????? ?????????????????????? ?????? ?????????? ???? ???????? ?????? ?????????????? ???? ???????????? ?????? ?????????? ???????? ??????.

Follow?Facile Technolab Pvt Ltd ?and?Prashant Lakhlani ?to read more content like this.