CODEWITHSUNDEEP
c#.netwcfasp.net-web-api
Callback Kid
Callback Kid

Reputation: 718

WCF much slower than WebAPI running same code

I currently have 2 exposed endpoints. The first is WebAPI (.NET 4.6). The second is WCF (.NET 3.5). They are both capable of performing the same calculation, however the WCF is on average 10 times slower. The calculation code in question is contained in a dll, lets call it core.dll. This dll also exposes the WCF endpoints and is used by an ASP.NET site. The webapi dll, lets call it api.dll references core.dll and is used by an SPA. The calculation can be triggered by either client. On average, with my test data, the WCF service takes about 4.5 seconds to perform the calculation, where as the WebAPI takes about 450 milliseconds (or about 10 times faster).

I should note that all database calls are done outside of the measured time frame. All data is retrieved before hand and all updates are made after the calculation has completed.

All things being equal is there any reason I could be seeing this big of a difference in pure processing speed?

I am 100% sure that the data is the same for both clients and they both receive the same result. 

WEBAPI Controller
    Service
        GRAB DATA
        start timer
        Process(DATA) -- the same code/class as below
        end timer
        UPDATE DATA
    Service return
WEBAPI Controller return

WCF Endpoint
    Service
        GRAB DATA
        start timer
        Process(DATA) -- the same code/class as above
        end timer
        UPDATE DATA
    Service return
WCF Endpoint return

EDIT: added diagram for clarity (hopefully)

EDIT 2: Thanks for the answers/comments. Unfortunately it doesn't look like anything conclusive will come of this question. My colleagues and I ultimately choose to believe that this just a pure difference in the efficiency of the Framework versions. We ended up restructuring the web service so that the calculation only happens in the WebAPI.

Upvotes: 11

Views: 2139

Answers (4)

Zer0
Zer0

Reputation: 7354

Use a profiler.

Get better data, out of process, without all the hastle. Profile both for CPU usage and memory, GC collections, hot path, etc...

That said...

You're comparing two vastly different .NET versions. That makes it impossible to do a fair benchmark.

.NET 4.6 introduced a new JIT for 64-bit that's significantly faster. And that's just one difference. Too many to list.

If you can't change the .NET version you will never get an accurate benchmark, but can look for suspects. I would absolutely use a profiler, but if benchmarking:

Take a look at the generated IL (pre-JIT) and also ensure you benchmark post-JIT (IL -> machine code).

One easy way is to simply run both benchmarks once (not measured) as a "cold start" before you start the actual benchmark.

Another is to use RuntimeHelpers.PrepareMethod prior to the benchmark to JIT methods so you're not measuring JIT time.

Of course, ensure your benchmark is fair.

Plenty of information out there, but ensure you're using high resolution timers, use a large sample size (repeat many times), Do a GC.Collect() before each measurement, use the same hardware (testing on the same box), etc...

Correctly doing benchmarks in-process (as opposed to profiling) is really not as easy as it looks.

Anything else is just speculation on our part. I couldn't really comment unless you posted real code that would reproduce your behavior.

Upvotes: 4

Shahar G.
Shahar G.

Reputation: 1510

Beside the performance improvements being mentioned in other answers here, I'd like to point out a very important distinction of choosing between WCF and Web API:

  1. You can get the same from both of them, but WebAPI is designed to work with HTTP (and mainly with JSON) and WCF needs more configuration to be HTTP (SOAP as default messaging).
  2. WCF have support for many sort of transportation protocols such as message queuing, one way messaging or duplex, TCP, HTTP of course and more.
  3. WCF can be configured in such a way that when 1 of the above is available and is faster than the others, it can be used like TCP or even UDP (on later versions)...
  4. Of course, every one of those channels needs configuration, which can be sometimes a pain in the neck.
  5. The WebAPI was designed to work with the HTTP, so it supports request/response, headers, media formats (text, JSON, jpeg, XML...), URI, caching and more.
  6. SOAP handling and transport is 'heavier' than JSON. Period. That's the main reason of preferring JSON over XML over the past 10 years or so.
  7. By choosing Web API when your service can be exposed to a vast range of clients, mainly browsers, but also mobiles!
  8. WebAPI is a light-weight framework which is good for smartphones having limited bandwidth.
  9. As mentioned, clients has evolved to be robust frameworks, like JQuery, Angular, Android and more. All need fast data transfer from the service. Currently, JSON is the most simplest and fastest way of handling data between client and server and WebAPI is working seamlessly with it.

So before coding it is better to know what each framework do the best and choose accordingly.

Upvotes: 1

Nick Polyderopoulos
Nick Polyderopoulos

Reputation: 909

My call is that you see such a difference because from .net 3.5 to .net 4.6 there were big performance boosts. If you do heavy use of framework elements that could be the issue.

Check the links bellow (They contain information about performance boosts):

Upvotes: 3

Ratatoskr
Ratatoskr

Reputation: 189

I think it's a combination of a few things. Namely the performance of REST (WebAPI) vs SOAP (WCF), especially depending on the amount of data being sent/received. As well as the fact that hosting a WCF service in ASP.NET, I don't think the service actually is running or initialized until it is called, so you'll have some initialization time.

Upvotes: 2

Related Questions