From the Blogosphere
WebSocket Technology | @DevOpsSummit #DevOps #APM #Microservices
Considerations and best practices
By: Tim Hinds
Feb. 16, 2016 11:15 PM
Providing a full-duplex communication channel over a single TCP connection, WebSocket is the most efficient protocol for real-time responses over the web. If you're utilizing WebSocket technology, performance testing will boil down to simulating the bi-directional nature of your application.
Introduced with HTML5, the WebSocket protocol allows for more interaction between a browser and website, facilitating real-time applications and live content. WebSocket technology creates a persistent connection between the client and server, circumventing the requirement for a client-initiated HTTP request to trigger a server response. Providing a full-duplex communication channel over a single TCP connection, WebSocket is the most efficient protocol for real-time responses over the web.
If you're utilizing WebSocket technology, performance testing will boil down to simulating the bi-directional nature of your application.
Synchronous vs. Asynchronous Calls
In addition to facilitating real-time applications, WebSockets are also used by web developers as a way of maintaining a faster, longer connection between client and server, even for traditional request-response purposes. This traditional request-response communication via WebSockets results in synchronous calls.
Asynchronous calls, on the other hand, do not require a client request to initiate a server response. The server automatically pushes information and updates over a single TCP connection (which remains open), allowing for an ongoing, bi-directional conversation.
Testers must be aware of the differences between the two in order to properly measure response times and validate the performance of their applications.
Because messages are generated by external events and the server decides when to send messages to all connected clients, it's in testers' best interest to measure the time it takes for a client to receive a message after the triggering of an external event.
The nature of asynchronous calls will change the logic required in designed load testing scenarios and testers will face many of the issues also associated with testing streaming media and long polling.
There are also a few browsers that don't support WebSocket communication. When this is the case, the application will replace the WebSocket communication with long polling. For performance engineers, this means creating two user paths for each use case (one using WebSockets, the other using long polling). To ensure realistic load testing, testers must take into account the ratio of browsers that are WebSocket compatible and ones that are not.
Tips for Load & Performance Testing WebSockets
Designing test cases for synchronous calls, again, is fairly simple as these calls employ traditional request/response communication. To measure their performance, you'll need to equip your testing team with a load testing solution that enables testing of synchronous calls over WebSockets.
Designing test cases for asynchronous calls is a bit more challenging. In this case, users connected via WebSockets will take a specific action from the moment information is displayed on the screen. For example, a user might decide to purchase stock when the price reaches a certain level. Otherwise, the user may take no action at all. Keep in mind, the user action included in your use case depends on the information that does or does not arrive via the WebSocket channel.
To combat browser incompatibility, you can introduce a WebSocket framework as a workaround. Otherwise, you'll need to design and execute polling scenarios during your load and performance testing.
The nature of WebSockets also poses challenges - it's a transport layer, so your project could be exchanging text data, binary data, etc. Performance engineers will need to decode or deserialize the WebSocket messages in order to correlate testing scenarios.
Ultimately, equipping your testing team with a load testing solution that not only provides the ability to test request-response apps that leverage WebSockets, but that can also manage the uninitiated responses sent by the server, will result in the most effective, realistic performance testing.
In terms of ensuring a seamless user experience, measuring the latency isn't enough. To truly validate the performance of an application utilizing WebSockets, you should combine your WebSocket load testing scenarios with scenarios on a browser-based tool like Selenium, but that is a topic for another post.
Latest AJAXWorld RIA Stories
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
SYS-CON Featured Whitepapers
Most Read This Week