WCF How much faster is TCP than HTTP
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?
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.
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.
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.
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.
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.