This 5-part blog series identifies five types of web applications that will benefit from HTML5 Web Sockets. For each of these scenarios, we will also show you where Kaazing WebSocket Gateway can be of additional value. This is part 2 of a series of 5 blog posts. Read the rest: Part 1.

Sign#2: You application must scale to large numbers of concurrent users

If you are building a web application for a large number of concurrent users, you are going to face resource contention. Every one of those users will establish a connection to your back-end application. Typically, each of those connections will include the overhead of HTTP’s verbose request-and-response protocol, as well as the possible establishment and teardown of connections.

The HTTP request and response model suffers from a significant amount of overhead. When retrieving a large document from a server, a few hundred bytes of HTTP header overhead is not a big deal. Consider what happens, however, when each message sent to a client is only a few bytes. For example, a stock price update that is only 20 characters long. The majority of the data transmitted in this case is unnecessary HTTP header overhead (up to 2000 bytes for the single stock price update), making the communication highly inefficient.

HTML5 Web Sockets specifies new, vastly more efficient way of communicating between clients and servers that is far less taxing on the application, and easier for the underlying network infrastructure to handle. Replacing hundreds of HTTP header bytes with just two WebSocket frame bytes leads to a massive reduction in unnecessary network throughput (up to 1000:1) as shown in the following figure

Figure 1. Comparison of unnecessary network throughput related to HTTP overhead between a polling Comet and Ajax solution (blue) and a WebSocket solution (orange) for three use cases: 1,000, 10,000, and 100,000 concurrent clients respectively at one-second intervals. In the 100,000 user case, the unnecessary network throughput is 665 Mbps versus 1.5 Kbps (less is better here!).

Additionally, Web Sockets’ lack of continuous polling dramatically reduces latency. All of this means that a single WebSocket server can deal with many more users at once, reducing the total cost of ownership (TCO) dramatically.

HTML5 Web Sockets provides such a dramatic improvement from the old, convoluted hacks that simulate a full-duplex connection in a browser that it prompted Google’s Ian Hickson—the HTML5 specification lead—to say “Reducing kilobytes of data to 2 bytes…and reducing latency from 150ms to 50ms is far more than marginal. In fact, these two factors alone are enough to make Web Sockets seriously interesting to Google.”

Kaazing WebSocket Gateway’s architecture is based on Staged Event-Driven Architecture (SEDA), and it leverages Java New I/O (NIO) for enhanced Java networking functionality. For example, instead of assigning a single thread per request, the server shares threads for optimal performance. This allows Kaazing WebSocket Gateway to achieve unparalleled levels of concurrent communication at extremely low message latency.