We benchmarked round-trip times with Secure WebSockets (wss://) vs HTTPS to see if there was a noticeable difference in response speed. For Secure WebSockets, we timed the difference between the client sending a “ping” packet, and the server responding with “pong”. This included going through an Akka router that managed the Play! Iteratees. For standard HTTPS, we timed the round-trip of the client initiating a request to an endpoint that immediately replies with “Ok”. The sample size is 1000 per type.
The median improvement using WebSockets was 3ms, which is slightly misleading due to the bimodal distribution of response times. On average (mean), we saw a 13ms round-trip improvement using WebSockets.
A few caveats:
- If you need to support a wide array of browsers, you will need to implement WebSockets along side other real-time techniques like long-polling, since IE doesn’t support WebSockets until version 10.
- This is only testing one aspect of real-time communication: client to server to client. For anything server to client, long polling already establishes a connection as well, so WebSockets should not have any advantage.
- HTTPS overhead is almost completely in the initial handshake. For the standard HTTPS requests, we configured the keep-alive so that the test is as fair as possible. For both, the initial handshake will take a few multiples of the average ping time.
- Since the WebSocket requests went through our Akka WS router, there was a slight additional overhead.
- We happen to be very close to our EC2 data center, so ping times for both are low. If your users are far from your nearest server, then this improvement may be completely negligible.
We wrote this post while working on Kifi — tools that help people outsmart information overload together. Learn more.