Do we remember our early experiences chatting with our friends on Orkut and feeling all obsessed with being able to send and receive messages in real-time. Fast forward to now, where we use Gmail and Slack, we have seen the rise of real-time web. These have been possible mostly because of WebSockets. Lets try to understand what WebSockets are, its features, and how to stress test our website from a performance standpoint.
What are WebSockets?
By definition, a WebSocket is a two-way computer communication protocol over a single TCP. WebSockets helps immensely to handle high scale data transfers between client and server. WebSockets are different because they work by holding the connection between client and server open at all times. Using this way, the server has the power to send information any time, even when it was not initiated by the client. Clients can still make usual HTTP requests to the server, while WebSockets open a medium between client and server to communicate.
What are WebSockets Good For?
WebSockets are good for situations where you need near real-time communications, such as the following:
- Online multiplayer games
- Chat apps
- Internet of things
- Real-time applications
- Sports scores/ticker
Benefits of WebSockets
- Continuous Connection between client and server. It makes it feasible to send information to client at any time, even without the client requesting it.
- Full duplex communication. Communication can be initiated by either way at any time both client and server are connected.
- Low Latency. As there is very limited overhead of HTTP headers, cookies, etc., it makes the speed at which data transfers are seamless and fast.
- HTTP Polling. This can help clients to keep polling the server for latest information. Polling is used by a vast number of applications today and most of the time it is used for RESTful practices.
Disadvantages of WebSockets
- WebSockets are more complex to use than HTTP. We can establish an HTTP connection with a Telnet, but can’t do the same with WebSockets.
- Load balancing and proxy setup with WebSockets is not possible.
- If in between connection drops, re-connection handling is not present in WebSockets.
Performance Testing Applications That Use WebSockets
As we have seen, WebSockets can help you support the chat sections or News Feed real time on our website, but it can possess performance issues which can impact overall user experience if not done neatly. To safeguard this we would be stress testing our website to find any performance or bottleneck issues with concurrent users located in geo distributed locations using LoadView.
Performance Testing with LoadView using The EveryStep Web Recorder
The EveryStep Web Recorder provides a screen recorder option while you’re browsing and helps you simulate the client side interactions with websites and applications. It supports over 40 desktop and mobile browsers, as well technologies used to create interactive content, such as Flash, HTML5, Java, PHP, Ruby, Silverlight, and more. We can record every step of our web transaction and replay our scripts in real browsers. It can help to test critical user paths and actions to uncover bottleneck and performance issues.
Let’s look at the steps and processes used to record scripts using EveryStep Web Recorder and then executing a load test using LoadView.
Open LoadView testing homepage. You may need to click on Create a New Load Test. Otherwise, we would see multiple types of tests available via LoadView like Web Applications, Websites, APIs, Streaming Media, etc. For our use case, we’re going to select the Web Application option to start recording the user’s journey.
We would get an option to Record New Script. Please enter website URL, browser type and user device type for the application we want our stress test to run and record our test case. Please click the Record Now button after adding details.
Clicking on the Record Now button will allow you the option to interact with the website under test and record steps we want to simulate. We would have the option to stop the recording once user flow is completed.
After successfully recording our script, we can review our test scenario using. Select the Play Now button or we can move forward to test by clicking the Continue button.
Clicking on Continue would redirect us to the Create Test window with the simulated actions script ready. We can name our test on this video and later we would need to click the Create Device button.
Once we have successfully created a device, we would see the Test Scenario screen, where we can set the load curve type, which can differ based on the goals of the load test.
- Load Based Curve. This is to execute load tests with a known number of users and raise traffic after set warm up time.
- Goal-based Curve. This test setup is used when we are looking for desired transactions per second for specific API, for example, and want to scale to the desired rate slowly.
- Dynamic based Curve. This set provides you to choose dynamic values in number of users, maximum users, and test duration. You can also change the load and load distribution, in real-time, during the test.
Based on the type of desired load test setup, we can click Continue, which will start execution of test with number of mentioned concurrent users and test duration. You can also choose from over 15 geo-locations to run tests from, ensuring that you’re measuring and testing performance from where your users are located.
After successful completion of load test run, we can see insights how the system under test behaved like response time graph, number of concurrent users graph, error count sessions.
Conclusion: Load Testing WebSocket-based Applications
As we have seen through this article with innovative technologies like WebSockets, and the new challenges it addresses, there are a lot of operational issues developers might face when using WebSockets as their real-time solution. Load tests on these applications are a must and it helps us estimate the behavior of our real-time application under load. We also went through, step-by-step, on how to test a WebSocket-based application using LoadView, along with the EveryStep Web Recorder, which can be extremely helpful to uncover major problems inherent in the WebSocket architecture.
Try the EveryStep Web Recorder now and see how easy it is to start scripting complex user scenarios. Sign up for the LoadView free trial and start running load tests for your WebSocket-based applications. You’ll get $20 in load testing credits to start.