Synthetic Monitoring
In the past few weeks, I’ve had several conversations about the announcement that Kaazing and Apica are teaming up to deliver performance monitoring for HTML5 WebSocket. I’ve found that many people are still largely unfamiliar with the HTML5 WebSocket standard, so I want to offer a clear explanation of how powerful the technology is, why it will quickly become the new standard for interactive web applications, and the challenges it presents in performance monitoring.
WebSocket is important
Similar to HTTP, the WebSocket standard is two parts. One part is the W3C’s HTML5 WebSocket APIs, which is implemented by the browser vendors, and the second part is IETF’s WebSocket protocol definition (RFC 6455) that is not bound to browsers, allowing other technologies to add support for this new standard.
Most commonly we refer to this new standard simply as HTML5 WebSocket, so you will soon see it prominently featured in any discussion of the technology. Like all of HTML5, it has important ramifications for mobile web applications, but the impact of HTML5 WebSocket will go far beyond mobile.
HTML5 WebSocket provides bi-directional, full-duplex communications channels across the web — something that current web technologies don’t really support. As a result, any interactive web application (such sites that stream real-time video or provide continuously updated stock prices) has had to resort to some very convoluted hacks to provide the interactive experience visitors expect.
HTML5 WebSocket is not just another incremental enhancement to conventional HTTP communications. It represents a colossal advance, especially for live, real-time, and event-driven web applications. It can reduce the kilobytes of overhead data needed to deliver an interactive web solution down to two bytes.
In terms of speed and scalability, the potential benefits of HTML5 WebSocket are tremendous. This video by Ericsson does a great job of illustrating how much faster WebSocket is than a more traditional HTTP connection.
Given the speed and quality of data transfer over more traditional web methods, I feel that HTML5 WebSocket will be a big hit in the market, and have a dramatic impact on the architecture of web applications. HTML5 is not fully supported by today’s browsers, but things are coming together quickly. Google Chrome, for example, already supports WebSocket and will shortly support a WebSocket debug API that will give developers a much better understanding of how WebSocket is working (or not working) in their applications.
Traditional monitoring won’t work with WebSocket
While HTML5 WebSocket promises to increase the scalability and performance of web applications for end users, supporting HTML5 WebSocket will be a challenge for IT operations. Specifically, it is unclear how IT can monitor and validate performance of this new setup. Classic browser or URL monitoring will not work on HTML5 WebSocket because it is a completely different protocol than HTTP.
If you use traditional web browser monitoring, you are only seeing a portion of the story. If you load a page with a graphic, you have a definite start and stop to the page. But if you are monitoring a page with a continuously updated stock ticker, there is no point at which the page stops loading. When do you stop monitoring if you’re only watching the web page?
The other part of the story that’s missing is the visibility into the data transfer. You can see the browser is connected on the status consol, but if there’s a data problem preventing the stock price from being updated, you would have no way of knowing.
Monitor the layers
There are three things driving the performance of a WebSocket web app: the data communications layer (being handled by the WebSocket protocol), the application layer, and the browser layer. In order to see the quality of the overall web application, you need to have a probe inside each layer, and that’s what we are driving in our announcement.
The data communications layer is pretty straightforward. Is it up? Can you reach it? What is the basic roundtrip speed and setup of the connection? It is a pretty standard application ping. You just need a tool that’s specific to the WebSocket protocol because it is not visible at the HTTP level at all.
The WebSocket standard is in essence TCP for the web and as such, was intentionally designed to extend the reach, similar to TCP, of higher-level transport protocols such as AMQP, XMPP, IRC, JMS, FIX, FAST, SQLNet, and security solutions like Kerberos. Understanding the actual data is harder because it needs to be specific for each individual application. For example, sending and receiving live information for stocks from a trading system using a messaging system supporting AMQP or JMS will be different than sending a position statement for a game. In order to understand the application, you need to have a small debug application running in monitoring mode that actually represents the window inside the browser.
To validate the application, you could run that separately and standalone. The data transport is pretty straightforward. It’s just for a standard application layer quality, given how many stock transactions per second you update. How many position statements for flying this helicopter that you’re transferring is harder because they need to understand the actual data and the applications transport protocol.
The application layer is the most difficult one to monitor because you need a good understanding of what the application is doing. If this is done in partnership with the developers, you can just take a snippet of the code and run that in the browser or standalone. You can drop it into the Apica framework, with a little debug around it as a monitoring object.
But if you come from the outside with no knowledge of what the application is doing, it will be virtually impossible to decode what’s happening in the application. So you need to have access to the source code of the application and a partnership with the developers.
The final layer is at the browser level. In the Apica framework, the browser monitoring is Selenium-driven, so it’s simple to record a web browser session and replay it during a load test. This way, it will actually do exactly what the user does.
This three-tier approach gives the operation better understanding on how the end user is viewing the application and greater granularity in error resolution and backend-problem tracking on the data WebSocket layer.
Why Kaazing and Apica
When we saw the need to support HTML5 WebSocket in our tools, Kaazing was the natural partner for us. It was involved in defining the HTML5 WebSocket protocol, so it brought a depth of understanding of the best practices in validating this type of transaction-in both the use cases and how to best represent the quality of communication. Apica understands how to monitor, and Kaazing understands how to design and architect programs that use WebSocket. That combined knowledge has created a strong tool for monitoring WebSocket-based applications.
Going forward
I hope this outline of the performance and scalability benefits of WebSocket has you thinking about how you can use this technology in your own environment. While we are certainly ahead of the curve, HTML5 WebSocket requires a totally different approach to monitoring than the current generation of web applications
My prediction is that the compelling benefits of HTML5 WebSocket will drive people to adopt this technology. Apica supporting technologies early in the adoption curve ensures that we will be able to help our customers perform capacity planning and load testing for their future needs.