Performance Improvement for Azure Web Apps

 One of the main features of PaaS services like Azure Web Apps is its ability to run and deliver great performance without any external configuration. Everything is managed out of the box for you by Microsoft Azure and you just reap the benefits of this exceptional service offering.

However, there may be scenarios when you are not getting the desired behaviour from your application in terms of performance even after doing all the regular tweaks. If you are convinced that there is nothing left to optimise within the application, but your resources are still under utilised like CPU/Memory, you can increase the minimum thread count available for your application. There are two types of threads available to your web application:

  1. Worker Thread – These threads are used for Processing your requests or performing background operations.
  2. I/O Thread – These threads are used whenever you are performing any I/O task like reading from external service or network.

By default, the minimum thread count for these two types of threads in an IIS application is set to the number of processors available in the machine. Whenever any new request comes in, these threads are used to serve the request if available, otherwise, a new thread is spun up based on the availability of system resources. The algorithm to create new threads might involve some delay which can extend up to 500ms. To avoid that, we can upfront set the minimum thread count for our application so that this overhead can be avoided. But make sure you don’t keep it too high which may cause further issues. The ideal number will depend upon the system configuration but you can start with a smaller number, say 50-100 and proceed gradually.

One way to set the minimum thread count is via ThreadPool class. In your application start code, add following line:

int min_worker = min_IO = 50;

ThreadPool.SetMinThreads(min_worker, min_IO);

You can read more about these settings in this excellent article by Jon Cole.

Comments

Post a Comment

Popular posts from this blog

Logging Strategy For Software Applications

  Logging Strategy For Software Applications Tarun Pabbi   /  February 19, 2020 Diagnostic logging within the software applications was a powerful tool in the initial stages of the software development, where we had very few IDE’s available and even lesser with debugging support. The best way to know your code execution was by adding log statements in the flow and then analysing the logs. Even recently we follow the same approach for client-side debugging in the browser by looking at the log statements in the console. But due to new powerful debugging tools and now even remote debugging capabilities in new IDE’s like Visual Studio we put less effort on log statements. Mostly they are added only after an issue occurs in the deployed version, due to which the quality and focus of the log statement tend to be towards the problem in hand instead of the holistic approach towards code execution. Another issue we encountered with logging is the performance impact. Usually, when we require a h
Read more

Automatically Cleaning Kubernetes Namespace

If you are working with Kubernetes, then chances are that you must have used namespaces to isolate your services or environments. Namespaces are a powerful way to organise your services or environments and have different policies like access control, ingress or telemetry configured for them. However, there might be scenarios where you have to clean these namespaces at specified time or interval. For example, if you have multiple developers working in your team and you want to provide them an isolated environment within your cluster (instead on their local setup, could be due to any reason like external dependency) you can use Kubernetes namespaces in this scenario. Now, when your developers want to test their code in K8s cluster, they can simply deploy their code to specific namespace(manually or through automated setup) and never worry about conflicting changes from other team members. You can have different namespaces with developer name or each git branch name. However, with this ki
Read more