High CPU load in IIS web server caused by HttpClient

High CPU load is one of the most common issues web servers struggle with. There could be several root causes such as deadlocks, insufficient hardware, high traffic, poor coding. In this post, I will explain the reason and solution for a high CPU load caused by an object which is not thread-safe.

This issue may surface in many ways. One if them is -obviously- high resource utilization. You can monitor the resource usage in Task Manager, Resource Monitor or Performance Monitor.

Before we go further, let’s remember what the thread safety is:

Thread safety is a computer programming concept applicable in the context of multi-threaded programs. A piece of code is thread-safe if it only manipulates shared data structures in a manner that guarantees safe execution by multiple threads at the same time.

Thread safety

High CPU load in Performance Monitor and Event Viewer

The Performance Monitor chart below shows that the CPU load is around 80% (red solid line). It also demonstrates how the error count (brown dashed line) increases in parallel to request total (green dashed line).

High CPU load displayed in Performance Monitor
High CPU load displayed in Performance Monitor

This issue may appear as error or warning messages in Event Viewer that seems unrelated to CPU load at first sight. The message below is recorded in the System container of Event Viewer and it mentions unresponsive application pool which points out high CPU load issue.

Event ID: 5010 (Warning)

A process serving application pool “X” failed to respond to a ping. The process id was “1234”


Root cause of the high CPU load

As I mentioned in the beginning of the post, there could be a variety of reasons why a web server suffers from high CPU load. In this scenario, the reason is that using an instance of a non-thread-safe object multiple times. More specifically, using the same HttpClient instance from different threads increases the CPU usage.

In official documentation for HttpClient, it is recommended to use only one instance of this object:

HttpClient is intended to be instantiated once and re-used throughout the life of an application. Instantiating an HttpClient class for every request will exhaust the number of sockets available under heavy loads. This will result in SocketException errors.

HttpClient Class

However, in practice, it is not a good idea especially for the scenarios where requests step on each other:

If you have requests that are related (or won’t step on eachother) then using the same HttpClient makes a lot of sense.

Best practice usage of HttpClient

If you are targeting the wrong CPU architecture (32-bit or 64-bit) that doesn’t match with your DLL libraries, this may cause an issue as well. Check this post out for a solution: How to find out processor architecture (x86, x64) of dll and exe files?

Solution for high CPU load

In many cases like this one, the application shouldn’t use only one instance of HttpClient. It causes requests to overlap each other and increase the CPU load.

Instead of calling the same instance of HttpClient (or the function that is creating HttpClient object), using a new instance of it should solve the high CPU usage issue.

If you don’t have CPU usage issue but your worker process (w3wp.exe) is crashing periodically, this post will help you to fix it: w3wp.exe crashes every 5 minutes with error code 0xc0000374

SocketException: No such host is known

Visual Studio provides all-in-one experience for software developers. From coding to testing, it makes IT professional’s lives easier. Error messages like “Socket Exception: No such host is known” refers to certain issues in the code or configuration of the application. In this post, I will explain the root cause and solution for this error message.

This error message may appear in may forms. Here is one of them:

System.Net.Sockets.SocketException: No such host is known

Error "No such host is known"

In some cases, you may see the exception code 0x80004005 along with the error message above. In addition, if you are receiving ThreadAbortException, check this post out.

The root cause of the “No such host is known” error

In the scenario I tested and in the online posts I reviewed, the root cause was the same: DNS name resolution failure. Basically, your application tries to call an API URL or to connect to a service but it is not able to find the hostname or your server is not able to do DNS lookup for that hostname.

Since it is an issue with DNS name resolution, nothing you do with Visual Studio, IIS, TFS or Windows will help fixing this issue. However, a simple code update may do the magic!

Similar issues on external sites: CodeProject, GitHub, Microsoft Support.

Another Visual Studio error: Remote Debugging Monitor (MSVSMON.EXE)

Solution for “No such host is known” error

The solution is fairly simple. Make sure your server is able to access to the DNS server and your DNS server is able to lookup the hostname in your code. Follow the steps below to troubleshoot and solve this issue.

  • In Command Prompt, run ipconfig /all. This will list the IP addresses of the DNS server you use. Try to ping them. Additionally, check with a colleague to see he or she has the same configuration
  • Run nslookup. Enter the hostname in your code. Make sure the DNS server is able to lookup this hostname.
  • Make sure there is no typo or white spaces in the hostname. If you are getting this input from a JSON call or configuration file, it is possible that the source string and the variable you have are different.

If this is an ASP.NET WebForms application, you may also come across Validation of viewstate MAC failed error. Follow the link for the specific solution for it.

PageMethods is not working (Solved)

PageMethods is a JavaScript class that you can use to call a server-side function. It’s basically an AJAX call which works asynchronously. In .NET world, you can use PageMethods to call a C# code-behind function. If you think that PageMethods is not working no matter what you do, keep reading.

For PageMethods to work, you need a JavaScript function on the client-side and a WebMethod function on the server-side.

Sample JavaScript code (Put it in asp:content section of Default.aspx):

<script type="text/jscript">

   function callCodeBehind() {
		PageMethods.GetMessage("test string", onSuccess, onFailure);
	}

   function onSuccess(result, usercontext, methodname) {
	   alert(result)
   }

   function onFailure(error, usercontext, methodname) { alert("failed: "+ error.get_message()); }

</script>

Sample C# code (code-behind file – Default.aspx.cs):

public partial class Welcome : System.Web.UI.Page
{
	protected void Page_Load(object sender, EventArgs e)
	{

	}

	[WebMethod]
	protected static void GetMessage(string val)
	{
		return "doingit";
	}
}

A button to call the JavaScript function (in Default.aspx)

<button onclick="callCodeBehind()">Click me</button> 

ScriptManager (in Site.Master – note that EnablePageMethods is set to True):

<asp:ScriptManager ID="ScriptManager1" runat="server" EnablePageMethods="True">
</asp:ScriptManager>

Having issues with your AJAX call as part of Google reCAPTCHA implementation? Check this post out.

What to do if PageMethods is not working

If you have the code above, your project should be working. In exceptional cases, you may not receive the return value. In my case, the issue was the post-back that was happening after clicking the button.

The reason behind the post-back was that friendy URL setting. As soon as I disabled it, my PageMethods function started working.

In order to disable friendly URL feature, remove or comment out the line below in your RouteConfig file.

routes.EnableFriendlyUrls(settings)
Successfully returned value

Are you losing data after a post-back? Here is what to do.

References: