LoadView is a cloud-based performance testing solution that provides test engineers the ability to quickly set up and execute load and stress tests on websites, web apps, APIs and web services, streaming media, and more. Cloud-based load testing provides you with a powerful infrastructure, but user-friendly interface, to run load and stress tests from a fully managed cloud environment. This article will cover the various options and considerations when choosing public cloud vs. public proxy vs. on-site load tests.

Unlike on-premises testing from your own machines, using a cloud environment frees up your time, money, and management so you can focus on load and stress testing instead of having to build and manage your own performance testing infrastructure and environment. Moreover, LoadView uses real browsers, instantiates user load from more than 20 geographical locations around the world, and provides multiple load curve options, giving you the ability to set up the most realistic test conditions.

Load Test Internal Applications with Ease

The LoadView solution allows you to leverage several options to test your websites and web applications from within your local network. Cloud-based load testing is a must for public web applications or websites.

However, what if a target web application is not available from the public Internet? Or maybe you are looking to test an application that will only be used within your organization. These internal applications or sites are critical to serving the business. Their performance is key to generating revenue, so performance testing is necessary, especially if these applications or sites are being used by large numbers of employees within a larger organization. For example, these could be internal finance or banking applications or web portals that are used by internal employees.

With the Public Proxy and Onsite Proxy Agent options, the LoadView solution is a viable alternative to internal load testing. Without a cloud-based solution like LoadView, organizations would have to have specialized teams and significant budget to carry out internal performance tests. Planning and setup could take weeks or months, resulting in expensive outcomes, like having to purchase additional hardware, managing licensing agreements, and having to bring in additional resources or teams for testing development and assistance.

With LoadView, these requirements and considerations are no longer necessary, as load injectors are provided and can be utilized from different areas of the world. In this article, we will give you an overview of the load testing approaches that are available for both public web applications and web apps behind the firewall.

Load Testing Options Target Type Do I Need to Configure the Firewall for Load Test? Network Proxy 
Public Cloud Available from the public Internet No Not in Use
Public Proxy Behind the firewall Whitelist the dedicated LoadView IP addresses. Public Proxy
Onsite Proxy Agent Behind the firewall No Onsite Proxy Agent

Public Cloud-based Load Testing with LoadView

When to use Public Cloud-based Load Testing

Use to load test web services, websites, or web applications that are available from the public Internet.

How to Set Up and Start the Load Test

  • Log in to you LoadView Account. Don’t have an account? Create a LoadView account now.
  • Make sure your firewall is open for inbound traffic and the target web resource is available from the public Internet.
  • Set up and run the load test. For a full step-by-step guide on how to create a load testing task and load test scenario, see our Target Configuration page on our Knowledge Base.

How Public Cloud-based Load Testing Works

  • To emulate virtual users, we launch Load Injector Servers (LIs) are launched with randomly allocated IP addresses using Amazon Web Services (AWS) and Azure Cloud Services.
  • The list of IP addresses used for the test can be downloaded right after the test starts. For more information and steps on retrieving load injector IP addresses, read our Getting List of Load Injector IPs Knowledge Base article.

Public Proxy for Cloud Testing Behind the Firewall

When to use Public Proxy for Cloud-based Load Testing

Use the Public Proxy option to load test web resources behind the firewall and when your firewall can be opened for inbound connections from the specific IP addresses. For this scenario, you need to allow traffic from Load Injector IP addresses in your network. In this case, use the public proxy option to run the test from predefined static IP addresses and whitelist these IP addresses in advance.

How to Set Up and Start the Load Test

  • Log in to your LoadView account or create a LoadView account now if you do not have one.
  • Whitelist LoadView Public Proxy IP addresses for each selected geo-zone in your firewall settings. A full list of LoadView Static Proxy IPs is available for reference on our List of Static Proxy IPs Knowledge Base article, as well as additional instructions and tips to whitelisting the EveryStep Web Recorder for web application load testing.
  • In the load test configuration and setup, in the Load Test Scenario, enable Network Proxy option and set it to Public. For additional information and test configuration steps, please read the Testing Behind a Firewall with LoadView Static Proxy Server Knowledge Base article.

How the Public Proxy Works

  • To emulate virtual users, we launch Load Injector Servers (LI) with static IP addresses.
  • All traffic is sent from the static IP addresses to your network.

Web Application Testing: Whitelisting the EveryStep Web Recorder

Web application load testing typically involves scripting user actions and running those scripts against high levels of load to gauge performance. The LoadView platform utilizes the EveryStep Web Recorder to create multi-step scripts for various user functions, such as shopping carts, login portals, forms, and much more. The EveryStep Web Recorder can be whitelisted from a dedicated IP address to allow for web application load testing.

For more information on how to whitelist the EveryStep Web Recorder, visit the List of Static IPs Knowledge Base article.

On-site Load Testing with LoadView Onsite Proxy Agent

When to Use the Onsite Proxy Agent

When you don’t want to open your firewall for any incoming traffic due to security reasons, use the Onsite Proxy Agent to load test web resources, such as websites and web applications, that are not publicly available.

How to Setup and Start the Load Test with the Onsite Proxy Agent

  • Log in to your LoadView account. If you do not have a LoadView account, you can create one here and get set up in minutes.
  • Install the LoadView Onsite Agent application on a dedicated Windows Server inside the same network as the target web resource. A list of system and hardware requirements can be found here. The Onsite Agent must be installed and enabled in order to continue.
  • Enable outbound traffic to Dotcom-Monitor services.
  • Set up the load test: in the Load Test Scenario enable the Network Proxy option and set it to Onsite Proxy Agents.

How the Onsite Proxy Agent Works

  • Once the Onsite Proxy Agent has been configured, it uses port 443 to send outgoing requests to the Dotcom-Monitor Service to check if any load tests were started for the corresponding target website and requests the load test configuration.
  • Once the test configuration with Load Injector IP addresses has been received by the Onsite Proxy Agent, it initiates multiple connections to these IP addresses from within the local network.
  • Load Injectors use the same connections to send load testing traffic to the Onsite Proxy Agent.
  • All load testing traffic to the target will be sent via the Onsite Proxy Agent from the company network.
  • Load testing results will be sent to LoadView and available in your LoadView account.

Monitoring from Behind the Firewall with Private Agents

Just as is performance testing from behind the firewall, sometimes it is necessary to monitoring websites, web applications, servers, web services, and network performance from behind the firewall. For this circumstance the Dotcom-Monitor platform provides the ability to set up Private Agents. These Private Agents don’t replace our network of global monitoring locations, rather they allow organizations to expand monitoring capabilities. For example, Private Agents allow organizations to analyze and compare ongoing performance between external locations and internal monitoring Agents. This provides insight into if performance issues are due to the internal network or application or perhaps some other external network issues, giving teams more accurate information needed for quick resolution.

The Private Agent feature, combined with our global monitoring locations, provides you with comprehensive and continuous monitoring performance for all your websites, applications, web services, networks, and more, all from the same interface. To learn more about Private Monitoring Agents, visit our Private Monitoring Agent Knowledge Base article. For information about system requirements, installing, and configuring Private Agents, see our Knowledge Base article about Private Agent Installation and Use. This article will guide you through the process of installing and configuring a Private Agent on your local server.