Why Companies Invest in Load Testing

Customers expect reliable websites, and if online services struggle, your buyers will move away to competitors. Recent research has shown that the clients are extremely impatient when it comes to slow loading services. Downtime is less critical than performance slowdowns. Up to 200 percent more people never return when they experienced unsatisfied response times.

Successful organizations understand that load testing is a must in their development chain, and they validate the performance of their systems during implementation and testing stages. Minor design decisions, such as framework, database, or caching can have a disastrous impact on scalability and stability of your new application. Even more, sizing of infrastructure is almost impossible without an appropriate load simulation. Oversized hardware is simply a waste of money. Recently, search engines have started to use response time metrics in their search engine rankings, which means if you spend real money on your SEO, you won’t rank well without fast loading sites.

Another reason for load testing is that organizations can validate the speed of new applications and compare them with given performance thresholds. This practice helps to identify slowdowns already during development stages, protects your customers from unsatisfied user experience and reduces the risks significantly.

How Does LoadView Work?

Load testing can be time-consuming and error-prone. We manage all tricky tasks for you, such as instantiating a load generator farm and creating worldwide distributed agents, which keeps you away from expensive setup or maintenance challenges. This gives you more time for the most important activities, such as test design, execution, and analysis.

Our LoadView solution is cloud-based. Everyone can execute a load test within minutes. Typically, projects hold back performance testing for the last minute, and they have no time for setup and integration of on-premises load simulation tools.

With LoadView this problem does not exist because it provides load injectors located in data centers around the world, fully managed by us. You as our customer can entirely focus on your test scenario, the execution, and the analysis.

Many load testing solutions provide just protocol-based user simulation approach, which is not enough. You can stress the server with protocol level testing, but a significant part of end-to-end response times is left out. Our LoadView platform gives you everything that you need when it comes to user simulation. You can choose between protocol, headless browser, or real browser-based testing.

5 Steps to Setup a Load Test

LoadView is completely web-based and highly intuitive. Forget the pain of spending days for complex installations. Just register for the free trial version or open your account and start load testing. We reduced the complexity of the load test setup, implementation, execution, and analysis dramatically. Whether you are an experienced performance engineer or new to load testing, it won’t take you more than a few minutes from script creation to the start of your test. LoadView guides you in the five steps outlined below through the whole load testing process.

Step 1: Create Your Load Simulation Script or Device

Keep in mind that there is no need to implement a high number of load testing scripts for your application. Often 20 percent of the use cases generate 80 percent of the total transaction load. Once you’ve selected the relevant user interactions, you should choose the appropriate user simulation approach. LoadView gives you full flexibility and provides protocol, headless browser, and real browser-based user simulation. After all, the objective of your load test and the technology used by your application will help you to find the appropriate simulation type.

Use protocol level scripts for stress tests to simulate a high load on the backend. Load or stress tests of web services typically use a protocol level simulation approach. Due to its low overhead, a high number of scripts can run in parallel on one load injector, which leads to less money being charged.

Real browser-based tests should be used to validate end-to-end response times. LoadView comes up with a capture and replays the script through our scripting tool called the EveryStep Web Recorder. Our customers love it because it lets you navigate through your test case and records your clicks. Once done, you can add timers to measure custom actions, add verification steps, and replay the recorded script. The EveryStep Web Recorder is part of our load testing and monitoring offering, and you can reuse it for automated execution of other repetitive tasks in your environment.

Step 2: Validation

Overloaded load injection machines impact end-to-end response times negatively. Therefore, LoadView provides a validation step, which executes a single user test of your test script and calculates the maximum number of users per load injection machine. Calibration prevents you from inconsistent test results due to bottlenecks on a load agent machine.

Step 3: Execution Plan

Marketing campaigns, sales, and other measures can have a huge impact on the number of hits arriving at your websites. Typically, the user requests land slowly in the morning and reach several highs over a full business day. It’s crucial to the success of your load test that you model a realistic execution plan. LoadView has various features that allow you to model a real-world load curve. You can specify how fast the user should be ramped up, how long a particular number of users should simulate the load, and also at what rate they should be ramped down. The execution plan feature of LoadView gives you full flexibility to model a realistic load test scenario.

Step 4: Zone Configuration & Virtual user distribution

We all know that network latency has an impact on web page load times. Consider a web page that downloads 2MB of content during refresh and 10ms for each back-end request.. The load time in your data center will be less than five seconds because of proximity and low latency. On specific locations abroad, such as Asia, with a latency of 200ms, the response times of this website will be five seconds for the back-end, and over 200ms for the network transfer.

Don’t make a mistake and measure response times only inside your data center. LoadView gives you a broad range of load injection machines around the world. Select those who represent the usual location of your customers.

Step 5: Run Your Test and Get Your Results

Finally, start your configured stress test scenario. The best thing is that you only pay what you get. Prior to the confirmation of a stress test, LoadView shows you how much you will be charged for the test. You will need to confirm your email address and LoadView will put your test in the execution queue.

During the load simulation, LoadView displays response time and throughput monitoring metrics in an online dashboard. Once the stress test has finished, you will receive a summary report with a link to the results of this test.

When scalability limits are exceeded during a stress test, the error rate is often high. Tuning and operational teams are typically interested in the cause of this issue. There is no need to repeat such tests because LoadView captures the full breakdown of your website response times. You can use the waterfall chart to get insight into the slow component or watch the video for visual checks how your website behaves under expected load situations.

Finally, you execute the test and received a detailed test report. The report is very intuitive, and you can review all results by using your browser. Furthermore, LoadView let you share test results by just sending out a unique link to your team. We removed the test reporting overhead completely.

Additionally, LoadView keeps previous test results that can be used to benchmark against new performance metrics after making changes to your application.

LoadView Cheat Sheet

This cheat sheet was created to provide concise information and should act as a guideline for your next performance test setting with LoadView.

What are the Use Cases for LoadView?

There are several critical scenarios where LoadView can help you to find the cause of a performance slowdown.

1. Scalability problem: When a new application slows down, and you have no idea why. LoadView can help you determine the load limit of your application.
2. Sizing: What type of hardware do we need for a new website? You can guess, but realize that the chance for an expensive failure is high. Oversized infrastructure is a waste of money, and a small server could result in massive performance problems.
3. Validate non-functional requirements: Your team documented detailed performance requirements. Under single user conditions the load times are acceptable but how will the new website behave under real production like load situations?
4. Concurrency: The functional test team reported that some features of the new site don’t respond to user input. This problem occurs randomly and often just when many testers are using those functions.
5. 3rd party services: Your developers build a content rich new website full with third-party scripts. Nobody has a clue how those external services behind third-party content will behave under normal or peak load conditions.

Technology Support

The look and feel of websites have dramatically changed over recent years. The decades of monotonous web pages are gone. Modern sites are full of fresh styles, videos, and other outstanding animations, which are appreciated by users, but are a pain for performance engineers because dynamic web pages are difficult to automate. LoadView lets you simulate virtually anything that can be rendered in a web browser. Your animated Flash application, dynamic AJAX, or Silverlight isn’t a problem anymore. With LoadView, you can create real browser-based scripts for all popular browsers, such as Internet Explorer, Chrome, or Firefox. You can also simulate major mobile devices, such as iPhone, Samsung, Nokia, or Blackberry. In total, LoadView supports more than 40 different desktop/mobile browsers and devices.

The nice thing with LoadView is that it protects your investments. There are no sunk costs when you implement user interaction scripts for load testing because you can reuse those directly for your uptime monitoring in production. Simply transfer those with a few clicks into our BrowserView or UserView monitoring solution. Also, the other way around is supported too.

Why Choose LoadView?

Speed rules our digital world. Companies large and small have integrated performance considerations into their development pipeline to meet user expectations. Our LoadView platform is designed for smooth and lean performance testing. Below are some good reasons why our customers have decided to use LoadView.

Reusability: Recycle load testing devices for uptime monitoring or create load testing devices from an uptime monitor. This guarantees maximum return from your investments.

Accurate user simulation: Measure response time, as perceived by your users, from around the world.

Ease of use: Forget the complicated setup procedures or on-premises load testing farms. Log into our web-based LoadView platform, specify your test setting, and execute the load test within minutes.

Time is money: LoadView lets you focus on the most important activities and charges only for load being simulated on your application under test.

Support: Our experts are always there for you to answer your questions.

LoadView Sample Scripts

LoadView supports three user simulation types and below are some sample scripts for each type.

Protocol-Based (HTTP/S, GET/POST Requests)

1. Choose HTTP or HTTPS
2. Add URL to your landing page
3. Set type GET or POST
4. Set full page download option (yes/no)

Headless (Single Page Browser Speed)

1. Set URL to your landing page
2. Set the timeout
3. Select the browser
4. Ignore certification errors (yes/no)
5. Set the response time calculation option

 Real browser based (Scripted Multi-Step Browser)

1. Start the Browser
2. Loads a YouTube video
3. Verifies the word “xslime”
4. Waits 10 seconds

LoadView Sample Test Report

Once your load test has finished, you will receive the test report, which provides an overview of the following performance metrics:

• Summary
• Execution plan
• Average and max response time
• Session overview
• Errors and error types
• Load on the load generator

The summary of this load test shows that we executed 178 sessions successfully, 6 sessions failed and 4.9 seconds was the average response time.

The execution plan shows the ramp-up and ramp down of our simulated user. It ramped up until 10 users.

The average response time of this test was 4.9 seconds. There was a spike 2.5 minutesafter the load test had started, with response times of above 8 seconds. Overall the response times are stable around 5 seconds.