Welcome!

Java Authors: Elizabeth White, Trevor Parsons, Andreas Grabner, Pat Romanski, Michael Bushong

Related Topics: Web 2.0

Web 2.0: Blog Feed Post

Performance Monitoring for HTML5 WebSockets

Kaazing and Apica team to deliver performance monitoring to apps using WebSockets

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.

 

Read the original blog entry...

More Stories By Jonas Jacobi

Jonas has 21 years of experience leading the development of innovative technology products and services. Together with Kaazing’s Co-Founder & CTO John Fallows, he pioneered and championed the groundbreaking HTML5 WebSocket standard. Prior to co-founding Kaazing he served as VP of Product Management for Brane Corporation, a Silicon Valley startup dedicated to developing a market-leading enterprise platform for building model-driven apps. Before Brane, he spent 8+ years at Oracle where he served as a Java EE and open source Evangelist, and was Product Manager in the Oracle Application Server division for JavaServer Faces, Oracle ADF Faces, and Oracle ADF Faces Rich Client. He is a frequent speaker at international conferences on accelerating and scaling secure enterprise-grade WebComms (Web Communications).

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.