CODEWITHSUNDEEP
performancehttpwebsocketjettythroughput
Aliaksandr Kazlou
Aliaksandr Kazlou

Reputation: 3301

Jetty WebSocket performance

On the Jetty page https://webtide.com/why-choose-jetty/ in the Throughput section it says:

We have designed Jetty for scalable performance under realistic loads of many simultaneous connections and we can achieve excellent results with many tens of thousands of HTTP connections and hundreds of thousands of simultaneous WebSocket connections.

So, what it is so different in the implementation of these 2 protocols, how Jetty can handle only tens of thousands of HTTP connections and in magnitude more WebSocket connections? Are WebSocket connections less expensive? How it can be? If both HTTP and WebSocket implementations utilize Java NIO (just guessing), why there is a difference in the performance then?

Upvotes: 1

Views: 1432

Answers (1)

jfriend00
jfriend00

Reputation: 707376

You can only really compare a webSocket connection to an HTTP connection if you measure something they have in common such as sending messages per second. If you are doing that, then a webSocket has a huge advantage in both bandwidth and in network traffic because it is an already established connection whereas an http connection must be re-established from scratch for every message and establishing that connection for every message has a cost.

Both a webSocket connection and an http connection have a bunch of overhead in order to set up the connection. There is, at a minimum, the TCP overhead of establishing a TCP connection which looks a bit like this:

enter image description here

Credit to this article

In addition a typical HTTP request will also include some overhead such as cookies and other headers.

The webSocket connection however, does this only once and then keeps the connection open so future messages can just be sent over that connection directly. The HTTP connection is temporal, it is connected, data sent, response received, then the connection is dropped. If you need to send another request, another HTTP connection must be established from scratch.

While the stateless nature of HTTP connections is great for conditions where a client only occasionally makes a request and often makes requests to different servers, it is NOT ideal if a given client is making lots of requests to the same host. In that case, it's much more efficient to establish one connection, keep that connection open and then just send messages over that existing connection when needed.

Given the general context of the article you mentioned and the other aspects it discusses, it appears that this difference is what that article is referring to when mentioning the difference in scalability.

Here's another related answer: Ajax vs Socket.io

Upvotes: 1

Related Questions