Today I’m not going to write much than sharing a list of blog posts that I came across. It is a nice read if you are interested in Azure DevOps or Deployment pipelines in General. Credit to JEREMY LINDSAY for creating everything-as-code-with-azure-devops-pipelines series.
Part 1 : C#, ARM and YAML
Part 2 : Multi-stage builds in YAML
Part 3 : Resource groups and YAML templates
Part 4 : Deploying an ARM template to create an Azure App Service with code
Today I’m going to write something about HttpClient inspired by ASP.NET community standup. The popularities of microservices and REST API’s are on it’s highest peak. Which makes us using HttpClient the most. While you are calling rest API using HttpClient, you need to be aware of few most important things.
- Do not create a new instance of HttpClient class for each request. Creating new object will create two problems.
- Each time the new connection will create a new connection pool for each request and it is a very costly operation as it includes 3-way handshake(HTTP) or even costlier TLS handshake(HTTPS)
- The second issue with this is it may lead to socket exhaustion because in whichever operating system environment you are in, you have limited sockets. You may think that you will dispose the object of HTTP client and you might not have parallel users equivalent to no of sockets(64K) but there is a catch here. Once you dispose of the object, socket does not get freed up immediately. The different operating system takes the different amount of time to free up the sockets(say 3-5 seconds). Hence this may lead you to reach handle limit.
- Do not create a single instance(static or singleton) of HttpClient. If you read the point one, you may conclude on creating the single instance of HttpClient because of it is thread-safe. This is said to be a more efficient way of creating HttpClient but it also has a serious issue. It will keep the connection open for a very long time. This has issue like
- It may lead to not respecting load balancing. What I mean by this is if your connection is opened with server X then all requests from your application will go to the same server and other servers might be in idle state. This may be a big problem when you are one of the highest load generator client of that API.
- The bigger problem comes when API uses things like Online-Offline (Blue-Green) deployment. On the toggle of API, Open connection with server keeps sending a request to it although it might have become an offline server.
- You might have some default header which you might not want to share between different clients.
This Leads to a conclusion that keeping either single or transient connection can cause many issues. It is always recommended to create connections smartly, some of the examples might be to create client per request kind and also keep refreshing the connection over a period of time. There can be many such solutions but use it smartly according to your need.