joydip_kanjilal
Contributor

Improving Web API performance

opinion
Mar 05, 20154 mins
Web Development

Take advantage of caching, asynchronous methods, content compression, and faster media type formatters to improve the performance of your Web API services

ASP.Net Web API is a lightweight framework used for building stateless HTTP services. You can use Web API to design and implement RESTful services that run on HTTP. REST is an architectural style — a set of constraints used to implement stateless services. Web API has already become the technology of choice for building light weight HTTP services. You can learn more on Web API from the asp.net site.

In this post I would like to present a few tips to improve the performance of your Web API services.

Use the fastest JSON serializer available

We frequently use JSON in lieu of XML for exchanging data between the service provider and the service clients primarily because JSON is light weight and hence the network bandwidth consumption for services that leverage JSON as a data exchange format is low compared to services that use XML. JSON serialization can affect your Web API performance to a considerable extent. You should select the JSON serializer that is fast and the payload is less. I do use Protobuf-Net a lot these days. Here is a performance comparison between the currently used binary serializers.

I prefer using Protobuf as it is the fastest available media formatter these days. Protocol buffers from Google provide you a fast, platform- and language-independent format for exchanging serialized data. You can learn more on Protocol Buffers from this article.

You can use Protocol buffers in your Web API services to reduce the payload and improve performance. You can get Protobuf from NuGet and install the formatter. The Protobuf-Net Media Formatter is easy to use and gives you the best performance compared to other media formatters. Next, you would need to register the formatter by specifying it in the Web API configuration.

Next, you should decorate the types you would like to be serialized in protobuf format using the ProtoContract attribute.

[ProtoContract]

    public class Customer

    {

        [ProtoMember(1)]

        public int Id { get; set; }

        [ProtoMember(2)]

        public string FirstName { get; set; }

        [ProtoMember(3)]

        public string LastName { get; set; }

    }

Alternatively, you can use the regular DataContract attribute on your type so that your type can be recognized by other formatters like JSON and XML while serializing data. However, you should specify the ordering explicitly while defining the type. The code snippet given below illustrates this.

[DataContract]

    public class Customer

    {

        [DataMember(Order = 1)]

        public int Id { get; set; }

        [DataMember(Order = 2)]

        public string FirstName { get; set; }

        [DataMember(Order = 3)]

        public string LastName { get; set; }

    }

Lastly, you should precompile your types using the static property called Model belonging to the ProtoBufFormatter class as shown below.

Use compression techniques

You should use compression techniques to compress the data that is transmitted over the wire. You can use GZip or Deflate compression on your Web API to compress data transferred between the server and the client. You can do the compression at the IIS level or by using a custom delegating handler or even using a custom action filter. You can learn more on how you can achieve this from this post.

Use faster data access strategies

The faster you can retrieve data from the database, the more responsive your Web API would be. I’d prefer to use classic ADO.Net over ORMs in most cases primarily because using ADO.Net is the fastest way to retrieve data from the database. If you need to use an ORM you should select the right ORM to suffice your requirements — a lightweight ORM will always fetch data faster compared to ORMs that are complete and are slow.

Database access is costly as far as performance is concerned. You should also reduce the number of roundtrips to the database as much as possible to improve the responsiveness of your Web API.

Use caching

You can use design your Web API in such a way that database hits and multiple requests to your Web API are eliminated. You can use caching to cache your Web API methods that are relatively stale — methods that would produce the same response with redundant calls and the response would only change infrequently. Similarly, you should cache data that is frequently used and relatively state.

Use asynchronous methods judiciously

You should implement asynchronous methods to maximize the number of concurrent requests that your Web API can handle at a given point of time. In using asynchrony properly, you can leverage the multiple cores in your system and maximize the application’s throughput. Throughput is defined as the measure of the amount of work done in a unit of time.

The following code snippet illustrates an asynchronous method that fetches data from the database asynchronously.

[HttpGet] 

public async Task<IEnumerable<Employee>> GetEmployee()

{

    return await dbContext.Payroll.ToListAsync<Employee>();

}

joydip_kanjilal
Contributor

Joydip Kanjilal is a Microsoft Most Valuable Professional (MVP) in ASP.NET, as well as a speaker and the author of several books and articles. He received the prestigious MVP award for 2007, 2008, 2009, 2010, 2011, and 2012.

He has more than 20 years of experience in IT, with more than 16 years in Microsoft .Net and related technologies. He has been selected as MSDN Featured Developer of the Fortnight (MSDN) and as Community Credit Winner several times.

He is the author of eight books and more than 500 articles. Many of his articles have been featured at Microsoft’s Official Site on ASP.Net.

He was a speaker at the Spark IT 2010 event and at the Dr. Dobb’s Conference 2014 in Bangalore. He has also worked as a judge for the Jolt Awards at Dr. Dobb's Journal. He is a regular speaker at the SSWUG Virtual Conference, which is held twice each year.

More from this author