Clicky

 

Learn about Load Testing

LoadView – A Techical Overview

 



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 intolerant 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 already in implementation and also in 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, also 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 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 keep 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-premise 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 unlimited 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 load testing, it won’t take you more than 5 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, service 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 use a protocol level simulation approach typically. 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 based real browser-based scripting tool called EveryStep. 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. EveryStep is part of our load testing and monitoring offering, and you can reuse it also 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 user 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. Considering a web page, which executes 50 sequential server requests during refresh and backend requests take 10 ms each. The Load time in your data center will be 5 seconds. On specific locations abroad, such as Asia with a latency of 200 ms, the response times of this website will be 5 seconds for the backend plus 200 ms x 50 requests equals 10 seconds for the network.

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 the confirmation of a stress test, LoadView shows you how much will be charged for this 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 in 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 fully browse through all results by using your browser. LoadView let you share test results by just sending out a unique link to your team. We removed the test reporting overhead completely.

LoadView keeps older test results for later comparison with new performance metrics allowing you to benchmark any 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 3rd party scripts. Nobody has a clue how those external services behind such 3rd party content will behave under normal or peak load conditions.

 

Technology Support

The look and feel of websites has 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 everything, which 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 such as IE, Chrome or Firefox or also simulate major Mobile devices such as iPhone, Samsung, Nokia or Blackberry. In total LoadView supports more than 40 different 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 re-use those directly for your uptime monitoring on production. Simply transfer those with a few clicks in our BrowserView or UserView monitoring solution. Also, the other way around is supported too.

Why Choose LoadView?

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

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

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

Ease of use: Forget the complicated setup procedures or on-premise load testing farms. Login to 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 POS
  4. Set full page download option to Yes or 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 relevant performance metrics such as

  • 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 2min 30 sec after the load test has started with response times of above 8 seconds. Overall the response times are stable around 5 seconds.