Windows Communication Foundation (WCF) is a distributed communication technology that ships as part of the .NET Framework 3.0. This article concentrates on comparing the performance of WCF with existing .NET distributed communication technologies. A prerequisite for this article is sufficient understanding of WCF. For an architectural overview of WCF please read “Windows Communication Foundation Architecture Overview” and to learn how to build services using WCF standard bindings please read “Introduction to Building Windows Communication Foundation Services” at http://msdn.microsoft.com/en-us/library/.
Goals
The goal of this article is to provide performance comparisons between WCF and other existing .NET distributed communication technologies. These technologies are:
- ASP.NET Web Services (ASMX)
- Web Services Enhancements (WSE)
- .NET Enterprise Services (ES)
- .NET Remoting
The scenarios and data presented in this article quantify the underlying cost of the different technologies. This data is useful in understanding the relation between these technologies and can be helpful in planning migrations between the technologies. However, care should be taken in the conclusions drawn from the data presented in this article. The limiting performance factor in a well-designed Service Oriented Architecture (SOA) solution is most likely the service implementation itself and not the cost of the underlying communication technology. One must measure each application to determine the performance characteristics of that application. Note that this article does not address performance best practices when using WCF. Rather, it endeavors to provide sufficient information to enable you to make informed performance decisions when you are using an existing .NET distributed communication technologies as a basis.
Comparisons
All data presented in this article was collected using the same hardware configuration: four 2-way client systems were used to drive a server that was configured as a Uni or Quad processor. Two 2 GB cards were employed to guarantee that the network was not the bottleneck for any of the scenarios. See Figure 14 for details of the topology employed.
The number of client processes used on the client systems was sufficient to ensure that the CPU on the server was completely saturated. The data collected and presented reflects the average of the multiple convergent runs and care was taken to make sure all data was highly repeatable and sustainable.
All the comparisons in article are throughput comparisons and as such higher the value achieved, the better it is. In all the graphs, the higher bars reflect better performance.
This article focuses on the server throughput of the .NET distributed communication technologies. This is defined as the number of operations for each second that these technologies can sustain. An operation is a request and reply message with little processing done by the service. As mentioned in the introduction, but reiterated here as it is critically important, it is expected that the business logic will dominate the cost of a service in a well constructed SOA solution. By leaving out business logic processing at the service, only the cost of the messaging infrastructure is measured.
The message payloads used are different based on the comparison scenario and are explained for each comparative technology.
ASP .NET Web Services (ASMX)
In this section the performance of ASP.NET Web services is compared with the performance of WCF. The scenario is request/reply between the client and the service. This is the typical message exchange pattern for both technologies. The request message in this scenario is required to send an integer. The reply message is comprised of an array of 1, 10 or 100 objects, each object being approximately 256 bytes long. The WCF object is an instance of a strongly typed data contract.
The signature of the function used to generate the message payload (objects) at the service is described in the following:
Order[] GetOrders(int NumOrders);
{
Order[] orders = new Order[numOrders];
for (int i = 0; i < numOrders; i++)
{
Order order = new Order();
OrderLine[] lines = new OrderLine[2];
lines[0] = new OrderLine();
lines[0].ItemID = 1;
lines[0].Quantity = 10;
lines[1] = new OrderLine();
lines[1].ItemID = 2;
lines[1].Quantity = 5;
order.orderItems = lines;
order.CustomerID = 100;
order.ShippingAddress1 = “012345678901234567890123456789″;
order.ShippingAddress2 = “012345678901234567890123456789″;
order.ShippingCity = “0123456789″;
order.ShippingState = “0123456789012345″;
order.ShippingZip = “12345-1234″;
order.ShippingCountry = “United States”;
order.ShipType = “Courier”;
order.CreditCardType = “XYZ”;
order.CreditCardNumber = “0123456789012345″;
order.CreditCardExpiration = DateTime.UtcNow;
order.CreditCardName = “01234567890123456789″;
orders[i] = order;
}
return orders;
}
IIS Hosted Interoperable Basic Profile 1.0 Web Service
This section compares the performance of ASMX and WCF while they are hosted in IIS 6.0. In both cases, no security is used. The WCF binding used is the BasicHttpBinding. This standard binding uses HTTP as the transport protocol. The Basic Profile specification can be found at http://www.ws-i.org/Profiles/BasicSecurityProfile-1.0.html. ASP.NET 2.0, part of the .NET Framework 2.0, provides CLR attributes to ensure conformance to the Basic Profile. For WCF the BasicHttpBinding provides the same level of guarantees.
As shown in Figure 1, WCF has improved performance over ASMX. Three different operation signatures (payloads) are shown in the graph. In each case an integer is passed from the client to the server and an array of objects (1, 10 or 100) is passed back to the client. WCF outperforms ASMX by 27%, 31% and 48% for 1, 10 and 100 objects in a message, respectively.
The graph in Figure 2 shows the throughput comparison of WCF and ASMX for the same scenario as Figure 1 but running on a quad processor. The throughput performance of WCF is better than ASMX by 19%, 21% and 36% for 1, 10 and 100 objects in a message, respectively. Note that the software used was not modified between the two configurations and a single service was exposed on the server. Comparing the data in the preceding two charts, the inherent scalability of the technologies can be noticed.
.gif)
Figure 1
.gif)
Figure 2
IIS Hosted Interoperable Basic Profile 1.0 Web Service using Transport Security
In this section, the performance of WCF is compared with the performance of ASMX with both operating over HTTPS. WCF uses the BasicHttpBinding for this scenario. Figure 3 shows the performance of WCF is better than ASMX when using transport level security. WCF outperforms ASMX by 16%, 18% and 26% for 1, 10 and 100 objects in a message respectively.
Figure 4 shows that the performance of WCF is better than ASMX by 5%, 12% and 13% for 1, 10 and 100 objects in a message respectively for a quad processor scenario.
.gif)
Figure 3
.gif)
Figure 4
Web Services Enhancements (WSE)
In this section, the throughput of WCF is compared with the throughput of Web Services Enhancements. The comparison in this case is with WSE 2.0 but it should be noted that the performance of WSE 2.0 and 3.0 are similar for this payload. The method signatures and payload used for this scenario are identical to that employed in the ASMX scenarios (shown in Section 3.1).
IIS Hosted Interoperable Web Service using WS-Security
In this section, message level security using X. 509 certificates as the security credential is used. The WSHttpBinding is used in WCF, which implements the WS-Security 1.1 specification. The transport protocol used is HTTP and the message exchange pattern remains request/reply.
Figure 5 shows WCF is much more efficient than WSE. The throughput of WCF is nearly 4 times better than WSE. The main reason for this is that WSE uses the System.Xml.XmlDocument class to do message level parsing, thereby loading the full message into memory at once, while WCF uses a streaming System.Xml.XmlReader class that improves the performance significantly.
Figure 6 compares the throughput of WCF and WSE 2.0 for quad processors. These results are similar to the performance gain achieved by WCF over WSE for single processor scenario. WCF is nearly 4 times faster than WSE with full message security.
.gif)
Figure 5
Figure 5 also illustrates the performance of another mechanism for securing messages in WCF: transport security with message credentials. This configuration combines transport-level security (HTTPS) and message-level credentials (for example, credentials in the SOAP message). To deploy this, WCF (Message Credentials) workload is using the BasicHttpBinding. The chart shows that the single processor scenario performance of WCF (Message Credentials) is better than WCF with WS Security by 129%, 166% and 277% for 1, 10 and 100 messages, respectively. The corresponding numbers for the quad processor scenario for WCF (Message Credentials) are even better and show an improvement of 126%, 156% and 248% for 1, 10 and 100 messages, respectively, over WCF (Message Credentials) for the uni processor scenario.
As can be seen from the chart, transport security with message credentials provides improved performance while still allowing rich message-level credentials. The message-level credentials include timestamp processing, canonicalization and signature processing. The message protection (signature, encryption, replay detection and other protection mechanisms) are still done at the transport byte stream level, below the individual message boundaries. There is a WS-Security header, but that only contains a timestamp, a security token and signature using that security token over the timestamp. Whereas, in the case where WCF uses full WS-Security, the message protection is done as a message-level transformation with signing and encryption done over the XML fragments for the headers and body. Also, the WS-Security header contains all the required security metadata as XML constructs. This extra XML-aware security processing and the larger size of the security header account for the performance difference. You have to consider the tradeoff between performance and security features available for the specific application that you might want to use this WCF setting in.
.gif)
Figure 6
.NET Enterprise Services (ES)
In this section, the throughput of Enterprise Services (ES) is compared with WCF using two different service operation signatures and payloads. These are referred to as primitive and order messages. The primitive message is of a primitive type and this allows ES to execute its fast serialization path. The order message is a typical scenario that imitates a book order online and is approximately 512 bytes. The request/reply message exchange pattern is used for these comparisons.
The signature of the primitive payload is as follows:
string TransferFunds(int source, int destination, Decimal amount);
Here the service just returns a string “successful” or “failure”.
For the order message the following code service is used:
static public ProductInfo CreateProductInfo(int count)
{
ProductInfo productInfo = new ProductInfo();
productInfo.TotalResults = count.ToString();
productInfo.TotalPages = “1″;
productInfo.ListName = “Books”;
productInfo.Details = new Details[count];
for (int x = 0; x < count; x++)
{
productInfo.Details[x] = GetDetail();
}
return productInfo;
}
static Details GetDetail()
{
Details details = new Details();
details.Url =
“http://www.abcd.com/exec/obidos/ASIN/043935806X/qid=1093918995/sr=k
a-1/ref=pd_ka_1/103-9470301-1623821″;
details.Asin = “043935806X”;
details.ProductName = “Any Book Available”;
details.Catalog = “Books”;
details.ReleaseDate = “07/01/2003″;
details.Manufacturer = “Scholastic”;
details.Distributor = “Scholastic”;
details.ImageUrlSmall =
“http://images.abcd.com/images/P/043935806X.01._PE60_PI_SZZZZZZZ_.jpg”;
details.ImageUrlMedium =
“http://images.abcd.com/images/P/043935806X.01._PE60_PI_MZZZZZZZ_.jpg”;
details.ImageUrlLarge =
“http://images.abcd.com/images/P/043935806X.01._PE60_PI_LMZZZZZZZ_.jpg”;
details.ListPrice = “29.99″;
details.OurPrice = “12.00″;
details.UsedPrice = “3.95″;
details.Isbn = “043935806X”;
details.MpaaRating = “”;
details.EsrbRating = “”;
details.Availability = “Usually ships within 24 hours”;
return details;
}
In these scenarios, the WCF service is self hosted and employs the NetTcpBinding.
Note You can use IIS 7.0, which is shipped with Windows Vista for hosting TCP services. In this case, the performance achieved is slightly less than the self-hosted case.
Self-Hosted Request/Reply TCP Application
This section compares WCF with ES for two payloads previously discussed without any security. Figure 7 shows that sometimes ES is faster while other times WCF is faster. The performance of ES is better by 21% for the primitive message payload when the fast serializer can be used (possibly on a handful of primitive types like integers) but WCF outperforms it by 149% for order message payload.
Figure 8 shows the same benchmark and payload comparison on a quad processor. As WCF scales better than ES, WCF is faster than ES by 7% for primitive message even though ES can utilize its fast serialization path. For the order message, WCF is faster than ES by 104%.
.gif)
Figure 7
.gif)
Figure 8
Self-Hosted Secure Request/Reply TCP Application
In this section, the performance of WCF and ES are compared for the same message loads as the previous section (Section 3.3.1) with security enabled. Specifically, transport-level SSL security is employed and ASP.NET Role principle is used for the authorization. Figure 9 shows that the performance of ES on a uni processor is faster than WCF by 24% for the primitive message type while for the order message type, WCF is faster than ES by 69%.
Figure 10 shows that for quad processor, ES is better than WCF by 16% for the primitive message type and for the order message type WCF is faster by 37%.
.gif)
Figure 9
.gif)
Figure 10
Secure Transacted Request/Reply TCP Application
In the previous two sections (Sections 3.3.1 and 3.3.2), the work done by the service was doing little more than creating the objects that were returned to the client. In this section, the throughput of WCF is compared with .NET ES when the services that are implemented use a database transaction. Please note that the transaction used is not flowed but is created and utilized within the service. The purpose of this scenario is to demonstrate that any substantial service implementation dominates the cost of the infrastructure independent of the technology used to deploy it. Hence the comparison is done only for the single proc scenario and only for primitive message type.
In Figure 11, WCF performance is compared with the performance of .NET Enterprise Service for a primitive message payload. As expected, the throughput of this scenario is significantly lower than the previous scenario because transactions are being used. Also as expected, the performance of the two technologies is nearly identical with WCF having slightly better performance.
.gif)
Figure 11
NET Remoting
This section compares the performance of WCF and .NET Remoting when communication is required across processes on the same machine. Three different sized payloads, each an array of bytes are used for this comparison. The following interface illustrates the service operation signature:
public interface IRemoteObject { [OperationContract] byte [] GetRBytes(int NumBytes); }
The size of the message payload returned is determined by the “NumBytes” which for the data below is 128 bytes, 4k and 256k. The NetNamedPipeBinding is employed without any security for this scenario.
Request/Reply Named Pipe Application
The cross-process named pipe is used as the transport protocol along with request/reply as the message exchange protocol. As seen in Figure 12, WCF outperforms .NET Remoting by 29% and 30% for message payloads of 128 bytes and 4k bytes, respectively. As the payload grows in size, the performance of the technologies converge so that for the 256k byte array the performance is nearly identical.
In Figure 13, the corresponding data for quad processors is shown. The throughput of WCF is better by 38%, 18% and 28% for message payloads of 128 bytes, 4k bytes and 256k bytes, respectively.
.gif)
Figure 12
.gif)
Figure 13
When migrating distributed applications written with ASP.NET Web Services, WSE, .NET Enterprise Services and .NET Remoting to WCF, the performance is at least comparable to the other existing Microsoft distributed communication technologies. In most cases, the performance is significantly better for WCF over the other existing technologies. Another important characteristic of WCF is that the throughput performance is inherently scalable from a uni processor to quad processor.
To summarize the results, WCF is 25%—50% faster than ASP.NET Web Services, and approximately 25% faster than .NET Remoting. Comparison with .NET Enterprise Service is load dependant, as in one case WCF is nearly 100% faster but in another scenario it is nearly 25% slower. For WSE 2.0/3.0 implementations, migrating them to WCF will obviously provide the most significant performance gains of almost 4x.
Performance Test Machine Configuration
.gif)
Figure 14
Figure 14 shows the machine configuration used is a single server and four client machines connected over two 1 Gbps Ethernet network interface. The server is a quad processor AMD 64 2.2 GHz x86 machine running Windows Server 2003 SP1. Each of the client machines are dual processor AMD 64 2.2GHz x86 machines running the same operating system as the server. The system CPU utilization is maintained at nearly 100%. All the scenarios that required hosting were done using an Internet Information Services (IIS) 6.0 server. For the single processor scenarios, the server is booted as a single processor machine.
Copy Code
SocialVibe