Apica, a performance testing and monitoring company teamed up with Kaazing to bring performance monitoring to apps using WebSockets. Kaazing customers moving applications to HTML5 and WebSocket extensions will now be able to validate response time and function with Apica’s real-browser monitoring to improve the end-user experience – Press Release.

Apica also published an excellent blog post about the Apica-Kaazing partnership, and some insight into WebSocket monitoring. The snippet below discusses the layers you need to think about when it comes to monitoring.

For a full read, head over to Apica’s blog: Apica and Kaazing: Why it works.

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.

• Kaazing Launches Its Platform in the Amazon Cloud
• The Web Communication Revolution – An Overview of HTML5 WebSockets
• WebCast: 5 Signs You Need HTML5 WebSockets
• Bulletproofing the WebSocket Wire Protocol