Welcome!

@DevOpsSummit Authors: Pat Romanski, Elizabeth White, Liz McMillan, Stackify Blog, Dana Gardner

Related Topics: @DevOpsSummit, Java IoT, Agile Computing

@DevOpsSummit: Article

How to Create the Most Realistic Load Tests | @DevOpsSummit #DevOps

The whole point of performance testing is to know that your app can handle whatever is thrown at it

You may have heard the phrase, "You've got to fake it till you make it."

Not with load testing.

Performance testing is one of the most important things you can do when building a web or mobile app, and it's only becoming more vital as the expectations of users are going up. People demand access to anything, anywhere, anytime, and they'll switch to a competitive solution if the app they're trying to use is slow or clunky.

Performance is critical to the success of your web and mobile apps - and will be for a long time in the future. It's not a matter of if you have to do it. It's about how to do it best.

So, how do you do it best? You make your test scenarios as real as possible. If you have ever listened to the performance testing horror stories from Brad Stoner, you've heard the importance of realistic testing scenarios

Why Is Realism So Important?
The whole point of performance testing is to know that your app can handle whatever is thrown at it. But application architecture, and in particular application delivery, is very complex. There are a lot of variables that impact the user's ultimate experience. Some are more obvious, like the specific device in use, or the task the user is trying to accomplish. Others are less apparent, hidden under abstraction layers or deep in the network layer.

You'll also want to consider the impact of other software running on the platform, the local environment, the ISP, and more. Not to mention the effect of 3rd-party services integrated with the app.

The list goes on. If your performance tests are overly simple, it means you aren't testing places that could impact the experience. It's like only testing a car on an empty highway and not taking the realities of street driving into account: potholes, traffic, other drivers, or suddenly-appearing pedestrians. Without realistic tests, you are not preparing for scenarios that are likely to happen and will be detrimental to your users (and your business). Plus you will be wasting a ton of time, effort, and money on useless tests.

So we've decided to put together a few ways that will show you how you can make your performance testing more realistic.

Don't Fake It - Realistic Load Test Scenarios Should Include...
Geography

Geographically speaking, where are your users? What are the predominant regions and how are people distributed between then? A user's geographic location plays a very important role in the experience they have and includes many factors that allow you to simulate load. The number of hops and the backbone speeds in the path between the website and the client system are just a couple of attributes involved in determining how fast packets will travel and how many packets are dropped.

Geographic diversity also shows you a range of user experience patterns, since people around the world may behave differently, especially when it comes to how people use desktops versus phones. Another important benefit of geographically dispersed load testing is the ability to distribute load across lots of places so your servers are handling traffic from a broader range of endpoints. Finally, using 3rd party locations forces you to execute your load tests outside of your data center, so they exercise the full data pathway from device to server.

Devices and Browsers
The web browser is the key blind spot for gaining true end-to-end visibility into application performance. Increased usage of client-side scripting means you must monitor the processing that takes place within the browser. It's the only way to get full visibility into performance. Browser test cases measure events that happen in the rendered page and are visible to the user. They can even measure things like: "After the user does A, how long does it take for button B to become enabled?"

Furthermore, you should monitor devices. Why? Because the variability in devices is growing rapidly. You need to look for software changes in each device and monitor their evolution and updates, which also impact performance. Here's the bottom line: With a little effort and maintenance, you can accurately find out if any clients are reacting poorly to your code, and work flexibly with your product to fix browser- or device-specific issues.

User Behavior
Accurately recreating the way users interact with your site is a key part of building realistic load tests. This usually starts with how you record scenarios in the first place. As users traverse through the app, you'll capture their clicks and form submissions and use this stream as the basis for future load tests. When you do this, you need to make sure the recording is parameterized in a way so that variables are randomized and represent what happens most often for people. All scenarios must be designed to be representative, replaying scenarios accurately with all the elements of users experience like popups or interruptions. So for example, if the user you are recording waits 10 seconds to click a button, you could turn this into a parameter that randomly waits between 5 and 20 seconds.

For even more realism, use Google Analytics to get a sense of the variability of parameters in actual users. While recording a scenario, you may need to specify some parameters that will be used for further test runs to help with repeatability. It is not a good practice to play back a test with the exact same recorded data for each user because it does not simulate real-life conditions. You should load test using special variables and store the desired data. Your requests can use this data during test runs.

User Paths
Sometimes, testers only test a limited set of paths through the application. This is often due to a limitation of the load testing software they are using. Take, for example, a chat window. This is small component on a typical web-based application, and as such, it's a part of the app that rarely gets tested. Other examples include infrastructure packages like Java Messaging Service or 3rd-party services like ad networks. If your load testing software doesn't help you incorporate these elements, you may have no idea how long those ads are making your users wait.

From the developer perspective, these experiences are somewhat separated from the application. But, this is not the case from the user's perspective. Think comprehensively about the way a user navigates through the app. Also talk to users. Ask about frustrations. This may lead to insights about how to build your performance tests with more realism.

Network Behavior
Knowledge about network latency and bandwidth is needed for any application that isn't local, because bumps and burps in the network can have a real adverse impact on your users. Monitoring network bandwidth and web application performance from multiple locations helps isolate problems in the network tier.

Bandwidth bottlenecks cause network queues to develop and data to be lost, impacting the performance of applications. This is especially true for mobile and cloud apps. High jitter, increased latency, and packet loss all work to degrade application performance. Use emulators and other monitoring functions to get a picture of the range of network characteristics. Then build that behavior directly into your load tests. Use your load testing platform to actually introduce network problems that users typically encounter, so you know what happens when they do.

Connection Parameters
Modern web browsers send requests to the server using several simultaneous connections. These parallel requests download images, scripts, CSS files and other resources located on the page. Different devices and browsers maintain different policies about how many concurrent requests are allowed. For example, phones generally restrict more than desktops or laptops do. You'll need to simulate an appropriate number of parallel requests during your tests. For example, if you are running an emulated mobile test from a server-based load simulator, make sure to set up some connection limitations. Try to send requests exactly like your browser did when you recorded your scenario. This makes the simulation all the more closer to real-world conditions.

Welcome to the Real World
It all boils down to one thing: keeping it real is paramount to load testing. We've given you a list of attributes to consider so that you can represent what actually happens for most users. If you can simulate what a user is most likely to experience, you'll be a step ahead of the game. With the rising demand for perfection in web application performance, there's no replacement for realistic load testing.

Image Credit: Jean-Etienne Minh-Duy Poirrier

More Stories By Tim Hinds

Tim Hinds is the Product Marketing Manager for NeoLoad at Neotys. He has a background in Agile software development, Scrum, Kanban, Continuous Integration, Continuous Delivery, and Continuous Testing practices.

Previously, Tim was Product Marketing Manager at AccuRev, a company acquired by Micro Focus, where he worked with software configuration management, issue tracking, Agile project management, continuous integration, workflow automation, and distributed version control systems.

@DevOpsSummit Stories
ChatOps is an emerging topic that has led to the wide availability of integrations between group chat and various other tools/platforms. Currently, HipChat is an extremely powerful collaboration platform due to the various ChatOps integrations that are available. However, DevOps automation can involve orchestration and complex workflows. In his session at @DevOpsSummit at 20th Cloud Expo, Himanshu Chhetri, CTO at Addteq, will cover practical examples and use cases such as self-provisioning infrastructure/applications, self-remediation workflows, integrating monitoring and complimenting integrations between Atlassian tools and other top tools in the industry.
"Storpool does only block-level storage so we do one thing extremely well. The growth in data is what drives the move to software-defined technologies in general and software-defined storage," explained Boyan Ivanov, CEO and co-founder at StorPool, in this SYS-CON.tv interview at 16th Cloud Expo, held June 9-11, 2015, at the Javits Center in New York City.
Is advanced scheduling in Kubernetes achievable?Yes, however, how do you properly accommodate every real-life scenario that a Kubernetes user might encounter? How do you leverage advanced scheduling techniques to shape and describe each scenario in easy-to-use rules and configurations? In his session at @DevOpsSummit at 21st Cloud Expo, Oleg Chunikhin, CTO at Kublr, answered these questions and demonstrated techniques for implementing advanced scheduling. For example, using spot instances and cost-effective resources on AWS, coupled with the ability to deliver a minimum set of functionalities that cover the majority of needs – without configuration complexity.
As Marc Andreessen says software is eating the world. Everything is rapidly moving toward being software-defined – from our phones and cars through our washing machines to the datacenter. However, there are larger challenges when implementing software defined on a larger scale - when building software defined infrastructure. In his session at 16th Cloud Expo, Boyan Ivanov, CEO of StorPool, provided some practical insights on what, how and why when implementing "software-defined" in the datacenter.
A strange thing is happening along the way to the Internet of Things, namely far too many devices to work with and manage. It has become clear that we'll need much higher efficiency user experiences that can allow us to more easily and scalably work with the thousands of devices that will soon be in each of our lives. Enter the conversational interface revolution, combining bots we can literally talk with, gesture to, and even direct with our thoughts, with embedded artificial intelligence, which can process our conversational commands and orchestrate the outcomes we request across our personal and professional realm of connected devices.