WCF How much faster is TCP than HTTP

Question

I understand that TCP is faster than HTTP for WCF but I'm interested to know by how much. I have a performance issue with a large application that uses HTTP and am considering whether moving to netTcp would yield a sufficient performance improvement to make the investment worthwhile.

Anyone know the difference in the amount of data sent by netTCP compared to Http bindings?

Cerallua

I'm just after a general figure for packet size. Are we talking roughly 2 fold difference or 100 fold? – Cerallua

packet size is configureable. I don't see how knowing just packet size will be of much if any use for troubleshooting performance problems. – Boykins

it depends, over HTTP you have SOAP but you also have lighter stuff like POX and JSON. So you are comparing netTcpBinding against what? – Heterosexual

Answer 1

So far lots of answers but no concrete data.

Microsoft produced a test to measure exactly what you asked about - the performance (throughput) difference between HTTP and TCP for WCF services. (The test didn't consider packet size!)

What this shows is that TCP/binary delivers nearly 2x the throughput of HTTP/xml, for the messages in this test. The bottleneck on this test was Server CPU, not network. Your results will vary because your messages will be more (or less) complex, your network will be more (or less) constrained, and your app code will be more (or less) CPU-intensive. But this gives you an idea.

Actually the Stocktrader benchmark was a competitive thing, comparing the performance of WCF on Windows Server to that of WebSphere on Linux. But as part of that, MS also compared the performance of WCF using HTTP to the performance of WCF using TCP.

download the full Stocktrader report

Erythropoiesis

That's great for a sales pitch. If the user had presented his question in such a way where he just wanted a single benchmark this would be a great answer. But, he said he has a real "performance issue" so this type of information is just not relevant. – Boykins

I completely disagree with your easy dismissal of this answer. The benchmark test approach is clearly documented in the paper, so that alone is worth something if he feels he needs to run his own tests. Also, all the source code for Stocktrader is available, including test scripts, so he could use that to get a huge leg up on implementing his own benchmark. Finally, it gives a much much better answer than the others that were here, which were something like "oh, I'd guess TCP would be faster." This is a real number, for one scenario. Not a guess. – Erythropoiesis

Thanks for the info. This was the kind of thing I was after. As everyone has suggested, I appreciate I need to run tests to find the bottleneck. however, it's useful to have this benchmark before I start the arduous process of setting up the environments and running the tests. – Cerallua

Do notice: The last bar measures TCP in "Self Hosted" mode. For production code you would probably want to host your TCP service in either a Windows Service or IIS 7.0/7.5 and I suspect this could impact the above results considerably. – Gunrunning

your link to picture is broken :) – Olmsted

Answer 2

Its not quite that simple. HTTP, TCP and other transport options have options to balance outside of just speed. Reliability can play a major role in the stability of your application depending on what it actually does. Don't just flip the protocol and run your program a couple times and consider that a good test. Read about the protocols and weigh the options against your requirements. Run some program, load, performance and network tests, preferably with the help of a qualified network admin.

Update: Since you changed your question I should also note that you need to figure out what is causing the performance loss rather than poking about measuring theoretical packet size. Like everybody else is saying, run tests.

Boykins

Of course I could run some tests. But before doing that I was just interested in knowing by what the difference in size of data between the two bindings, just a rough factor. – Cerallua

Answer 3

According to the ISO/OSI model, TCP is a transport layer. HTTP is an application layer implemented on top of TCP. So HTTP will always have added overhead, no matter what.

Generally. if HTTP solves a fair amount of your application-layer problems then use it, because it's well-established, highly interoperable and proven. If you need to do a fair bit of work to get things going even when your application uses HTTP, and things get better and simpler with TCP, then by all means, go for a lower-level protocol.

Specifically regarding WCF, I have no idea what their TCP-only implementation looks like. I'd wager it's simpler than HTTP though. HTTP is probably used as a "bulletproof" communications medium, and the cost of the HTTP overhead is justified by the fact that the protocol easily traverses proxy servers, etc.

Agnes

Answer 4

The most expensive part of WCF is serialization, I think. Compared to that, the overhead of a webserver stack is about 5-10%, which the TCP-only transport does eliminate. Question is, do you need the added benefits of a webserver.

Blowzy

Answer 5

Do some tests! It depends on your network and what your service is actually doing.

Generally it will be faster because TCP connections are lower in the stack and don't have the overhead of creating a new request once a connection is open.

Wheeze

when I say faster I meant the difference in packet size. I've edited question – Cerallua