WCF [modified]
-
What exactly did you measure? Call time from client to the server? WCF does lot more processing and is lot more flexible so I would expect it to be slightly slower. But in real world applications where other things such as data storage and network transfer is involved, the slowness of WCF vs ASMX is not at all significant.
I was interested in overall performance, so that's what I measured. Specifically, the time it took to return a business object or datatable n times - the full round-trip. I did use BasicHttpBinding for this; maybe I should have used wsHttpBinding or otherwise messed with the settings. Also, I ran these tests over a network, and they hit the database, so they were a real-world evaluation, if only on a limited scale; that was sort of the idea. As for a decrease in speed, it troubles me because, compared to properly configured .NET remoting, Web services are 10-20% slower (although I haven't tested that one myself). Add another 10-20% on top of that and suddenly the difference is anything but negligible. I'm willing to take one hit (maybe) to save some effort, but I'd rather not run at two-thirds the speed of another program with identical functionality. //TODO: Sig
-
I was interested in overall performance, so that's what I measured. Specifically, the time it took to return a business object or datatable n times - the full round-trip. I did use BasicHttpBinding for this; maybe I should have used wsHttpBinding or otherwise messed with the settings. Also, I ran these tests over a network, and they hit the database, so they were a real-world evaluation, if only on a limited scale; that was sort of the idea. As for a decrease in speed, it troubles me because, compared to properly configured .NET remoting, Web services are 10-20% slower (although I haven't tested that one myself). Add another 10-20% on top of that and suddenly the difference is anything but negligible. I'm willing to take one hit (maybe) to save some effort, but I'd rather not run at two-thirds the speed of another program with identical functionality. //TODO: Sig
any Http Binding will be slow as it is, by design, a verbose character-based communication (be it SOAP, XML or any other newfangled protocol). I think the strength in WCF is its configurability, you can develop a service using HttpBinding on your local machine, and deploy it to a Tcp bound binary communication layer (much like remoting in previous frameworks). Think of it is web services, and inter-process communication all wrapped into one (not very?) neat bundle.
-
I was interested in overall performance, so that's what I measured. Specifically, the time it took to return a business object or datatable n times - the full round-trip. I did use BasicHttpBinding for this; maybe I should have used wsHttpBinding or otherwise messed with the settings. Also, I ran these tests over a network, and they hit the database, so they were a real-world evaluation, if only on a limited scale; that was sort of the idea. As for a decrease in speed, it troubles me because, compared to properly configured .NET remoting, Web services are 10-20% slower (although I haven't tested that one myself). Add another 10-20% on top of that and suddenly the difference is anything but negligible. I'm willing to take one hit (maybe) to save some effort, but I'd rather not run at two-thirds the speed of another program with identical functionality. //TODO: Sig
I must say that I am surprised with the results. In my tests the performance difference due to WCF/WebServices was insignificant. Of course, performance matters in the context of your application. If WCF is slow and you are not getting any benefits from WCF then it does not make any sense to migrate your application to WCF.
-
I just finished testing the performance of WCF against Web Services and was surprised to find that it was actually considerably slower (10-20%) in all of my (admittedly trivial) tests. Does this match up with what other people have found? My understanding was that it was meant to be faster, justifying the absurd amount of configuration you have to go through to use it. //TODO: Sig
modified on Monday, July 27, 2009 8:15 AM
The default config options (ie the ones that are assumed if you don't configure them) are not geared to high performance. One area to look at is serviceThrottling, amongst others. Here's an article I was reading the other day which you might find handy: http://weblogs.asp.net/sweinstein/archive/2009/01/03/creating-high-performance-wcf-services.aspx[^]
print "http://www.codeproject.com".toURL().text Ain't that Groovy?
-
The default config options (ie the ones that are assumed if you don't configure them) are not geared to high performance. One area to look at is serviceThrottling, amongst others. Here's an article I was reading the other day which you might find handy: http://weblogs.asp.net/sweinstein/archive/2009/01/03/creating-high-performance-wcf-services.aspx[^]
print "http://www.codeproject.com".toURL().text Ain't that Groovy?
Nice article, particularly point 2 - I'd heard something about that before but hadn't been able to replicate it. Now if only we used exclusively SQL databases...
//TODO: Sig -
I just finished testing the performance of WCF against Web Services and was surprised to find that it was actually considerably slower (10-20%) in all of my (admittedly trivial) tests. Does this match up with what other people have found? My understanding was that it was meant to be faster, justifying the absurd amount of configuration you have to go through to use it. //TODO: Sig
modified on Monday, July 27, 2009 8:15 AM
Steve Westbrook wrote:
My understanding was that it was meant to be faster
Hmmm. Here's what is claimed. A Performance Comparison of Windows Communication Foundation (WCF) with Existing Distributed Communication Technologies[^]
Steve Westbrook wrote:
the absurd amount of configuration you have to go through to use it.
Yes, it introduces configuration hell! :)
Kevin
-
I was interested in overall performance, so that's what I measured. Specifically, the time it took to return a business object or datatable n times - the full round-trip. I did use BasicHttpBinding for this; maybe I should have used wsHttpBinding or otherwise messed with the settings. Also, I ran these tests over a network, and they hit the database, so they were a real-world evaluation, if only on a limited scale; that was sort of the idea. As for a decrease in speed, it troubles me because, compared to properly configured .NET remoting, Web services are 10-20% slower (although I haven't tested that one myself). Add another 10-20% on top of that and suddenly the difference is anything but negligible. I'm willing to take one hit (maybe) to save some effort, but I'd rather not run at two-thirds the speed of another program with identical functionality. //TODO: Sig
Steve Westbrook wrote:
compared to properly configured .NET remoting, Web services are 10-20% slower
uh, you're comparing apples and oranges then. .Net Remoting uses binary serialization which has a much smaller payload than HTTP binding. Consequently the times with WCF will be slower. Try using NetDataContract or DataContract binding instead. It's much more comparable to .Net Binary Serialization. Also, remove the DB calls if you want to have comparable timings. The db access will introduce it's own random latency which will confuse the timings.
-
I just finished testing the performance of WCF against Web Services and was surprised to find that it was actually considerably slower (10-20%) in all of my (admittedly trivial) tests. Does this match up with what other people have found? My understanding was that it was meant to be faster, justifying the absurd amount of configuration you have to go through to use it. //TODO: Sig
modified on Monday, July 27, 2009 8:15 AM
Yes its bit slower, If you use the default config. But once you set/use following, you will see the speed improvements (in my case it was from bit slower to super fast). 1) Use DataContact instead of binary / xml serialization 2) Use serviceThrottling with
maxConcurrentSessions=xx3) Change default value of following to more appropriate value (or set it to max)maxReceivedMessageSize maxBufferPoolSize maxBytesPerRead4) Use different behavior for different contract, so that you can change the value as per the service requirements. (Don’t use common behavior for all the contracts) 5) Change the value of Send/Receive Timeout, if you are getting frequent timeouts. -
Steve Westbrook wrote:
compared to properly configured .NET remoting, Web services are 10-20% slower
uh, you're comparing apples and oranges then. .Net Remoting uses binary serialization which has a much smaller payload than HTTP binding. Consequently the times with WCF will be slower. Try using NetDataContract or DataContract binding instead. It's much more comparable to .Net Binary Serialization. Also, remove the DB calls if you want to have comparable timings. The db access will introduce it's own random latency which will confuse the timings.
In order of appearance: I'm measuring techniques to move data from one place to another. In that context, the comparison seems valid to me - I care how long the user has to wait, not how I write the code. If all you want is something to eat, and you have one very specific criterion for what constitutes good food, comparing apples to oranges is possible. I believe the analogy stands. Presumably you mean the NetDataContract and DataContract attributes. These are not binding types; you appear to be confusing binding with serialization. The performance difference remains when using a business object and a DataContract attribute - that is, when the data is serialized into binary format. HTTPBinding does have a significant overhead; at the moment I'm looking at NetTCPBinding as an alternative. Other than the first call, DB call timing variations are typically negligible, and as with any statistical variation, approach zero with sufficient repetitions. Again, this is an attempt to measure real-world performance, and so I needed to test these methods in something approximating a real-world situation. I could worry about processor and memory availability changing too, but in the end it all comes out in the wash.
-
In order of appearance: I'm measuring techniques to move data from one place to another. In that context, the comparison seems valid to me - I care how long the user has to wait, not how I write the code. If all you want is something to eat, and you have one very specific criterion for what constitutes good food, comparing apples to oranges is possible. I believe the analogy stands. Presumably you mean the NetDataContract and DataContract attributes. These are not binding types; you appear to be confusing binding with serialization. The performance difference remains when using a business object and a DataContract attribute - that is, when the data is serialized into binary format. HTTPBinding does have a significant overhead; at the moment I'm looking at NetTCPBinding as an alternative. Other than the first call, DB call timing variations are typically negligible, and as with any statistical variation, approach zero with sufficient repetitions. Again, this is an attempt to measure real-world performance, and so I needed to test these methods in something approximating a real-world situation. I could worry about processor and memory availability changing too, but in the end it all comes out in the wash.
Regardless, the serialization method you use will significantly effect the size of the payload sent over the wire. DataContractSerialization is simiar to XMLSerialization. You stated you were comparing WCF with HTTPBinding to .Net Remoting. The size of the payload will significanly impact the time it takes to transmit over the wire. This has two problems: 1. By default, .Net remoting uses Binary Serialization. Binary Serialization produces much smaller payloads than DataContract Serialization. The NetDataContractSerializer will produce payloads similar in size to BinarySerialization. 2. .Net Remoting is a connection protocol, whereas HTTPBinding is connectionless. Why is this important? Each time you make a method call in WCF/HTTPBinding it will reconnect to the server. In .Net remoting, this is not the case -- the port remains connected. Hence reconnecting for each method call is expensive. Using WCF / net.tcp will eliminate this difference. Unless the call throws an exception, in which case you must close and reconnect. Hence due to these two reasons, when comparing .Net Remoting and WCF / HTTPBinding you can not reasonably expect similar timings.