What is the ASP. NET Web API
The ASP. NET Web API is a framework that uses the HTTP services and makes it easy to provide the response to the client request. The response depends on the request of the clients. The Web API builds the HTTP services, and handles the request using the HTTP protocols. The request may be GET, POST, DELETE, PUT. We can also say that the ASP. NET Web API:
- Is an HTTP service.
- Is designed for reaching the broad range of clients.
- Uses the HTTP application.
We use the ASP. NET Web API for creating the RESTtful (Representational State Transfer) services.
The following are some important points of the ASP. NET Web API:
- The ASP. NET Web API supports the MVC application features that are controller, media formatters, routing etcetera.
- It is a platform for creating the REST services.
- It is a framework for creating the HTTP services.
- Responses can be formatted by the APIs MediaTypeFormatter into the Java Script Object Notation (JSON) and Extencible Markup Language (XML) formats.
Architecture of Web API
What the Windows Communication Foundation (WCF) is
WCF is also a framework but it creates a service-oriented application. It can send the data asynchronously from one endpoint service to another service. The endpoint service can be the part of the continuous available service that is hosted by the IIS. There are some important points of WCF:
- WCF sends the data asynchronously.
- It is a secure service to process the business transaction.
- The message that is send can be a single character or a word sent as XML.
- It includes the chat service that allows the two people for exchanging the data.
Architecture of WCF.
To choose between Web API and WCF:
- You can choose the Web API when you want to create the service that uses all the HTTP features, such as request and response header, URIs, versioning etcetera.
- You choose the Web API if you want to expose the HTTP services to a broad range of clients. These includes the mobile , iPhone and browsers.
Now define the reason of choosing the WCF:
- You can choose the WCF if you want to create the service that supports one-way messaging, message queues, duplex communication etcetera.
- You can choose the WCF if you want to create a service that uses the fast transport channel, such as TCP, UDP, Named pipe etcetera.
WCF is Microsoft’s unified programming model for building service-oriented applications. It enables developers to build secure, reliable, transacted solutions that integrate across platforms and interoperate with existing investments. (ASP.NET Web APIis a framework that makes it easy to build HTTP services that reach a broad range of clients, including browsers and mobile devices. ASP.NET Web API is an ideal platform for building RESTful applications on the .NET Framework. This topic presents some guidance to help you decide which technology will best meet your needs.
What is the ASP. NET Web API
The ASP. NET Web API is a framework that uses the HTTP services and makes it easy to provide the response to the client request. The response depends on the request of the clients. The Web API builds the HTTP services, and handles the request using the HTTP protocols. The request may be GET, POST, DELETE, PUT. We can also say that the ASP. NET Web API:
- Is an HTTP service.
- Is designed for reaching the broad range of clients.
- Uses the HTTP application.
We use the ASP. NET Web API for creating the RESTtful (Representational State Transfer) services.
The following are some important points of the ASP. NET Web API:
- The ASP. NET Web API supports the MVC application features that are controller, media formatters, routing etcetera.
- It is a platform for creating the REST services.
- It is a framework for creating the HTTP services.
- Responses can be formatted by the APIs MediaTypeFormatter into the Java Script Object Notation (JSON) and Extencible Markup Language (XML) formats.
Architecture of Web API
What the Windows Communication Foundation (WCF) is
WCF is also a framework but it creates a service-oriented application. It can send the data asynchronously from one endpoint service to another service. The endpoint service can be the part of the continuous available service that is hosted by the IIS. There are some important points of WCF:
- WCF sends the data asynchronously.
- It is a secure service to process the business transaction.
- The message that is send can be a single character or a word sent as XML.
- It includes the chat service that allows the two people for exchanging the data.
Architecture of WCF.
To choose between Web API and WCF:
- You can choose the Web API when you want to create the service that uses all the HTTP features, such as request and response header, URIs, versioning etcetera.
- You choose the Web API if you want to expose the HTTP services to a broad range of clients. These includes the mobile , iPhone and browsers.
Now define the reason of choosing the WCF:
- You can choose the WCF if you want to create the service that supports one-way messaging, message queues, duplex communication etcetera.
- You can choose the WCF if you want to create a service that uses the fast transport channel, such as TCP, UDP, Named pipe etcetera.
WCF is Microsoft’s unified programming model for building service-oriented applications. It enables developers to build secure, reliable, transacted solutions that integrate across platforms and interoperate with existing investments. (ASP.NET Web APIis a framework that makes it easy to build HTTP services that reach a broad range of clients, including browsers and mobile devices. ASP.NET Web API is an ideal platform for building RESTful applications on the .NET Framework. This topic presents some guidance to help you decide which technology will best meet your needs.
Choosing which technology to use
The following table describes the major features of each technology.
WCF
ASP.NET Web API
Enables building services that support multiple transport protocols (HTTP, TCP, UDP, and custom transports) and allows switching between them.
HTTP only. First-class programming model for HTTP. More suitable for access from various browsers, mobile devices etc enabling wide reach.
Enables building services that support multiple encodings (Text, MTOM, and Binary) of the same message type and allows switching between them.
Enables building Web APIs that support wide variety of media types including XML, JSON etc.
Supports building services with WS-* standards like Reliable Messaging, Transactions, Message Security.
Uses basic protocol and formats such as HTTP, WebSockets, SSL, JQuery, JSON, and XML. There is no support for higher level protocols such as Reliable Messaging or Transactions.
Supports Request-Reply, One Way, and Duplex message exchange patterns.
HTTP is request/response but additional patterns can be supported through SignalRand WebSockets integration.
WCF SOAP services can be described in WSDL allowing automated tools to generate client proxies even for services with complex schemas.
There is a variety of ways to describe a Web API ranging from auto-generated HTML help page describing snippets to structured metadata for OData integrated APIs.
Ships with the .NET framework.
Ships with .NET framework but is open-source and is also available out-of-band as independent download.
Use WCF to create reliable, secure web services that accessible over a variety of transports. Use ASP.NET Web API to create HTTP-based services that are accessible from a wide variety of clients. Use ASP.NET Web API if you are creating and designing new REST-style services. Although WCF provides some support for writing REST-style services, the support for REST in ASP.NET Web API is more complete and all future REST feature improvements will be made in ASP.NET Web API. If you have an existing WCF service and you want to expose additional REST endpoints, use WCF and the WebHttpBinding.
The following table describes the major features of each technology.
WCF
|
ASP.NET Web API
|
---|---|
Enables building services that support multiple transport protocols (HTTP, TCP, UDP, and custom transports) and allows switching between them.
|
HTTP only. First-class programming model for HTTP. More suitable for access from various browsers, mobile devices etc enabling wide reach.
|
Enables building services that support multiple encodings (Text, MTOM, and Binary) of the same message type and allows switching between them.
|
Enables building Web APIs that support wide variety of media types including XML, JSON etc.
|
Supports building services with WS-* standards like Reliable Messaging, Transactions, Message Security.
|
Uses basic protocol and formats such as HTTP, WebSockets, SSL, JQuery, JSON, and XML. There is no support for higher level protocols such as Reliable Messaging or Transactions.
|
Supports Request-Reply, One Way, and Duplex message exchange patterns.
|
HTTP is request/response but additional patterns can be supported through SignalRand WebSockets integration.
|
WCF SOAP services can be described in WSDL allowing automated tools to generate client proxies even for services with complex schemas.
|
There is a variety of ways to describe a Web API ranging from auto-generated HTML help page describing snippets to structured metadata for OData integrated APIs.
|
Ships with the .NET framework.
|
Ships with .NET framework but is open-source and is also available out-of-band as independent download.
|
Use WCF to create reliable, secure web services that accessible over a variety of transports. Use ASP.NET Web API to create HTTP-based services that are accessible from a wide variety of clients. Use ASP.NET Web API if you are creating and designing new REST-style services. Although WCF provides some support for writing REST-style services, the support for REST in ASP.NET Web API is more complete and all future REST feature improvements will be made in ASP.NET Web API. If you have an existing WCF service and you want to expose additional REST endpoints, use WCF and the WebHttpBinding.
Goal
This post compares WCF and WebAPI technologies from the performance perspective.
Service description
I implemented almost same service in two different ways. Both are accessible via HTTP/REST and both works in the way to skip the serialization in order to isolate logic which could impact the performance results.
Both services implements GET and POST requests:
- GET request to return a string with current time
- POST request to accept a data and return back the same data in the stream
I self-hosted both services and run them via Full Azure emulator.
My own test agent
The first approach was stress testing via my own implementation, very similar to the way described here:http://www.ducons.com/blog/tests-and-thoughts-on-asynchronous-io-vs-multithreading). I was able to get cca 4000 request/sec but it had the following drawback that the test agent used more CPU than server so that the results were not real, the whole system run on 100% CPU. I think, it was mainly due to overhead connected with TPL and HttpClient.
Azure Load testing
This approach wasn’t successful neither, I created and setup the azure load testing (max number of users without any delays) but I was able to run max little bit over 2000requests/second.
Appache Benchmark
I knew this tool from my past and using it was worth again! It’s built on sockets, which has the minimal overhead (compared to HttpClient). There is also a similar benchmark done by Rick Strahl but I’ve measured a little bit different numbers.
WCF service details
class TestService : ITestService
{
public Stream TestGet()
{
return new MemoryStream(Encoding.UTF8.GetBytes("Hello World. Time is: " + DateTime.Now));
}
public async Task TestStream(Stream requestStream)
{
using (var reader = new StreamReader(requestStream))
{
var body = await reader.ReadToEndAsync();
return new MemoryStream(Encoding.UTF8.GetBytes(body));
}
}
}
WebAPI service details
public class TestController : ApiController
{
public HttpResponseMessage Get()
{
return new HttpResponseMessage() { Content = new StringContent("Hello World. Time is: " + DateTime.Now, Encoding.UTF8, "text/plain") };
}
public async Task Post(HttpRequestMessage inputMessage)
{
var content = await inputMessage.Content.ReadAsByteArrayAsync();
var response = new HttpResponseMessage { Content = new ByteArrayContent(content) };
return response;
}
public async Task Put(HttpRequestMessage inputMessage)
{
var content = await inputMessage.Content.ReadAsStreamAsync();
var response = new HttpResponseMessage { Content = new StreamContent(content) };
return response;
}
}
Thanks to feedback from Joakim:
As you can see, WebAPI has POST and PUT request support. The reason is, that StreamContent turns the response to the chunked transfer mode and I wanted to compare chunked and unchunked modes.
Performance tests
I run both services locally on my machine (Dell XPS12, i7, SSD). In each test I issue 60000 requests with concurrency set to 100. POST requests sent and received 500 bytes over the network. Here are the commands and results:
GET request to WebAPI
ab -n 60000 -c 100 -k http://localhost:8082/api/test
Server Software: Microsoft-HTTPAPI/2.0
Server Hostname: localhost
Server Port: 8082
Server Hostname: localhost
Server Port: 8082
Document Path: /api/test
Document Length: 41 bytes
Document Length: 41 bytes
Concurrency Level: 100
Time taken for tests: 8.042 seconds
Complete requests: 60000
Failed requests: 0
Write errors: 0
Keep-Alive requests: 60000
Total transferred: 13860000 bytes
HTML transferred: 2460000 bytes
Requests per second: 7460.40 [#/sec] (mean)
Time per request: 13.404 [ms] (mean)
Time per request: 0.134 [ms] (mean, across all concurrent requests)
Transfer rate: 1682.96 [Kbytes/sec] received
Time taken for tests: 8.042 seconds
Complete requests: 60000
Failed requests: 0
Write errors: 0
Keep-Alive requests: 60000
Total transferred: 13860000 bytes
HTML transferred: 2460000 bytes
Requests per second: 7460.40 [#/sec] (mean)
Time per request: 13.404 [ms] (mean)
Time per request: 0.134 [ms] (mean, across all concurrent requests)
Transfer rate: 1682.96 [Kbytes/sec] received
GET request to WCF
ab -n 60000 -c 100 -k http://localhost:8080/wcf/test/testget
Server Software: Microsoft-HTTPAPI/2.0
Server Hostname: localhost
Server Port: 8080
Server Hostname: localhost
Server Port: 8080
Document Path: /wcf/test/testget
Document Length: 41 bytes
Document Length: 41 bytes
Concurrency Level: 100
Time taken for tests: 7.333 seconds
Complete requests: 60000
Failed requests: 0
Write errors: 0
Keep-Alive requests: 60000
Total transferred: 13800000 bytes
HTML transferred: 2460000 bytes
Requests per second: 8181.73 [#/sec] (mean)
Time per request: 12.222 [ms] (mean)
Time per request: 0.122 [ms] (mean, across all concurrent requests)
Transfer rate: 1837.69 [Kbytes/sec] received
Time taken for tests: 7.333 seconds
Complete requests: 60000
Failed requests: 0
Write errors: 0
Keep-Alive requests: 60000
Total transferred: 13800000 bytes
HTML transferred: 2460000 bytes
Requests per second: 8181.73 [#/sec] (mean)
Time per request: 12.222 [ms] (mean)
Time per request: 0.122 [ms] (mean, across all concurrent requests)
Transfer rate: 1837.69 [Kbytes/sec] received
POST request to WebAPI
POST request is implemented in NON-CHUNKED transfer mode.
ab -n 60000 -c 100 -p c:\temp\data500.txt -k http://localhost:8082/api/test
Server Software: Microsoft-HTTPAPI/2.0
Server Hostname: localhost
Server Port: 8082
Document Path: /api/test
Document Length: 508 bytes
Document Length: 508 bytes
Concurrency Level: 100
Time taken for tests: 8.729 seconds
Complete requests: 60000
Failed requests: 0
Write errors: 0
Keep-Alive requests: 60000
Total transferred: 39480000 bytes
Total POSTed: 40267000
HTML transferred: 30480000 bytes
Requests per second: 6873.25 [#/sec] (mean)
Time per request: 14.549 [ms] (mean)
Time per request: 0.145 [ms] (mean, across all concurrent requests)
Transfer rate: 4416.60 [Kbytes/sec] received
4504.64 kb/s sent
8921.24 kb/s total
Time taken for tests: 8.729 seconds
Complete requests: 60000
Failed requests: 0
Write errors: 0
Keep-Alive requests: 60000
Total transferred: 39480000 bytes
Total POSTed: 40267000
HTML transferred: 30480000 bytes
Requests per second: 6873.25 [#/sec] (mean)
Time per request: 14.549 [ms] (mean)
Time per request: 0.145 [ms] (mean, across all concurrent requests)
Transfer rate: 4416.60 [Kbytes/sec] received
4504.64 kb/s sent
8921.24 kb/s total
PUT request to WebAPI
PUT request is implemented in CHUNKED transfer mode.
ab -n 60000 -c 100 -u c:\temp\data500.txt -k http://localhost:8082/api/test
Server Software: Microsoft-HTTPAPI/2.0
Server Hostname: localhost
Server Port: 8082
Document Path: /api/test
Document Length: 0 bytes
Document Length: 0 bytes
Concurrency Level: 100
Time taken for tests: 10.079 seconds
Complete requests: 60000
Failed requests: 0
Write errors: 0
Non-2xx responses: 60001
Keep-Alive requests: 60000
Total transferred: 10020167 bytes
Total PUT: 40207569
HTML transferred: 0 bytes
Requests per second: 5953.22 [#/sec] (mean)
Time per request: 16.798 [ms] (mean)
Time per request: 0.168 [ms] (mean, across all concurrent requests)
Transfer rate: 970.90 [Kbytes/sec] received
3895.90 kb/s sent
4866.81 kb/s total
Time taken for tests: 10.079 seconds
Complete requests: 60000
Failed requests: 0
Write errors: 0
Non-2xx responses: 60001
Keep-Alive requests: 60000
Total transferred: 10020167 bytes
Total PUT: 40207569
HTML transferred: 0 bytes
Requests per second: 5953.22 [#/sec] (mean)
Time per request: 16.798 [ms] (mean)
Time per request: 0.168 [ms] (mean, across all concurrent requests)
Transfer rate: 970.90 [Kbytes/sec] received
3895.90 kb/s sent
4866.81 kb/s total
POST request to WCF
ab -n 60000 -c 100 -p c:\temp\data500.txt -k http://localhost:8080/wcf/test/teststream
Server Software: Microsoft-HTTPAPI/2.0
Server Hostname: localhost
Server Port: 8080
Server Hostname: localhost
Server Port: 8080
Document Path: /wcf/test/teststream
Document Length: 508 bytes
Document Length: 508 bytes
Concurrency Level: 100
Time taken for tests: 9.365 seconds
Complete requests: 60000
Failed requests: 0
Write errors: 0
Keep-Alive requests: 60000
Total transferred: 41880000 bytes
Total POSTed: 40928100
HTML transferred: 30480000 bytes
Requests per second: 6407.15 [#/sec] (mean) Time per request: 15.608 [ms] (mean)
Time per request: 0.156 [ms] (mean, across all concurrent requests)
Transfer rate: 4367.37 [Kbytes/sec] received
4268.11 kb/s sent
8635.48 kb/s total
Time taken for tests: 9.365 seconds
Complete requests: 60000
Failed requests: 0
Write errors: 0
Keep-Alive requests: 60000
Total transferred: 41880000 bytes
Total POSTed: 40928100
HTML transferred: 30480000 bytes
Requests per second: 6407.15 [#/sec] (mean) Time per request: 15.608 [ms] (mean)
Time per request: 0.156 [ms] (mean, across all concurrent requests)
Transfer rate: 4367.37 [Kbytes/sec] received
4268.11 kb/s sent
8635.48 kb/s total
Summary
The measured results showed that WCF is faster than WebAPI when sending GET requests but slower when executing POST request in non-chunked mode. My results are different than Rick’s results little bit. WCF proved to be faster in some scenarios and I think all depends on the data payload. My take-away from it:
- I have a base line for the further service development
- both platforms are “fast enough” for me and I’m going to stay with WebAPI as it looks to be more appropriate for building further real RESTfull service development but I wrote about it in my previous article.
No comments:
Post a Comment