Eating your own dogfood: Fixing some common pitfalls when consuming your own Web API's

Sunday, March 1, 2015
by Sean McAlinden

I recently had an interesting discussion with a colleague regarding a set of RESTful services which utilise other internally built web API's to build responses, commonly described as "Eating your own dog food".

Architecturally the whole concept of exposing your services as API's and utilizing them within other web API's and applications within your business makes absolute sense to me, there are many benefits to this approach which have been discussed many times and is not a controversial statement, however what is sometimes less known is how this approach may bottleneck.

In this post I am going to discuss servers and connections, a crucial and often unknown major performance bottleneck.

Incoming Server Connections (HTTP)

The IIS webserver is fantastic, it can efficiently handle loads of incoming connections on it's listener threads and distribute them accordingly, this is just as well as it would not really function as a web server otherwise.

It would be absolutely reasonable to say that IIS as with many other webservers was built with handling multiple incoming connections in mind.

Outgoing Server Connections (HTTP)

As webservers are configured for lots of inbound http connections, unfortunately this means that by default they are not configured for lots of outbound connections.

By default, IIS only allows for 2 connections to a specific IP address from each AppDomain within your process... 

Don't panic though, this can be configured.

Configuring the Outbound HTTP MaxConnection in IIS

Now whilst this is easy to configure, if your initial though it so set this to a really high number, be warned that the overall performance of the server will degrade (there is a reason it is not set high by default).

There are recommendations for the ServicePointManager maxconnection settings however in reality you need to test various configurations until you reach the correct balance.

To illustrate though, some recommend 12 X CPU count, this would give you 96 connections on an 8 X CPU machine.

You can achieve this by adding the following to your application start:

ServicePointManager.DefaultConnectionLimit = 12 * Environment.ProcessorCount;

There are also other settings within the ServicePointManager which can be used to improve performance such as Nagle which I would recommend looking into.

I hope this has been useful and will maybe save someone from some hard to find performance issues.