#HTTP BENCHMARK CODE#
Sure, you can do socket programming, but why bother? Lots of people have spent a lot of time and effort building HTTP client libraries and servers, and they have spent waaaaaay more time optimizing and testing that code than you will ever be able to possibly spend on your TCP sockets. the only reason you would otherwise think about using raw TCP is for a possible performance boost) you should probably just use HTTP.
In general, if what you want to accomplish can be easily done over HTTP (i.e.
#HTTP BENCHMARK HOW TO#
A sensible strategy is to implement the simple version first, but have plans in your head for how to make it faster. Another is that HTTP would make it easier to implement a load balancer between the IIS server and the backend systems.įinally, at the end of the day it is probably more important that your system is secure, reliable, maintainable and (maybe) scalable than it is fast. For example, you are less likely to run into firewall issues if you use HTTP than if you use TCP on some random port. There are other issues that might affect your choice. depending on the details of your application. But it may also be considerably more work to implement. In theory, an optimally designed / implemented solution using TCP will be faster than one that uses HTTP. A generic HTTP vs TCP benchmark won't answer your question, because the chances are that the benchmark won't match your application behaviour. The answer is that it depends on the nature of your application, and on the way that you use TCP and/or HTTP in your application. The question you really need an answer for is "will TCP or HTTP be faster for my application". Where as general web focused companies will opt to use HTTP and use IIS or Apache to host their services. In general performance oriented system like those in the military or financial sectors will probably use plain TCP connections. Which begs the question: what kind of data are your services outputting? binary (video, audio, files) or text (JSON, XML, HTML)? Note that it doesn't really compare apples to apples since it compares the TCP/Binary data option with the HTTP/XML data option.
See page 5, it has the performance graph. The only thing to consider is the usage rate of modern web browsers among your users see for the latest info regarding browser compatibility.Īs for benchmarks, this is the only thing I found. However, many modern browsers now (as of 2013) support API's to access network, audio, and video resources directly via JavaScript. For a non-modern browser to directly consume TCP connections without HTTP you would have to use Flash or Silverlight and this normally happens for rich content such as video and/or audio. If you are doing something that might be directly consumed by a browser (through an AJAX call) then you should use HTTP. You may want to consider HTTP because of its ease of use and simplicity which ultimately reduces development time. If performance is the only thing you care about then plain TCP is the best solution for you. So naturally using TCP sockets will be less heavy than using HTTP.
HTTP is a layer built ontop of the TCP layer to some what standardize data transmission.
0 kommentar(er)
