Information for: DEVELOPERS   PARTNERS   SUPPORT

Looking for something?

Load and stress testing

It’s important to ensure your application and its hosting platform can handle the traffic you expect. Using load testing, you can evaluate your application’s future performance under controlled circumstances. You may also want to perform load testing if you expect one of your applications to experience a surge in popularity for whatever reason.

Note

Be sure to contact Acquia Support before any expected high-traffic events.

This page describes how to prepare for and carry out load testing on Acquia Cloud Enterprise. Since Cloud Platform Professional website rely on shared load balancing infrastructure that’s being used by other subscribers, Acquia doesn’t permit load or stress testing with these applications. For more information, see Testing for Cloud Platform Professional.

Even though you may have experience evaluating your application’s performance using security and penetration testing or vulnerability scans, load testing can require a significant amount of extra preparation and resources. For information about Acquia Cloud Enterprise subscription and infrastructure requirements, see Load testing requirements.

Applications with more than 5% authenticated and non-cacheable traffic should have a load test targeting the most common use cases, and the same is true for websites having a large amount of anonymous traffic or a significant number of editorial users. Ideally, you should perform load tests before the following events:

  • Launching a new infrastructure configuration
  • Launching a major change to an application’s code (including a new theme, a mobile version of the application, or a new splash page)
  • Initiating a major marketing campaign

Guidelines for load testing

To perform a load test in the safest and most effective manner, review the load testing requirements for your Cloud Platform configuration, which are based on the following guidelines:

  • Use only dedicated equipment for a load test Cloud Platform Enterprise subscribers can buy dedicated equipment for testing. This includes the web stack, search farms, and load balancers. This prevents the extreme resource use generated by a load test from affecting other subscribers. Contact Acquia Support both to provision load test equipment and to schedule a load test. A load test is meaningful only if the test is run on a clone of the production stack. If there are no live applications on the Production environment, you can run tests directly on Production.
  • Provide Acquia with at least five business days’ notice before a load test If temporary infrastructure is needed, Acquia will need more lead time to place the infrastructure. At a minimum, Acquia needs the date and time of the load test and the list of the individual originating IPs that will generate traffic. These IP addresses must be individual IP addresses, and can’t be IP address ranges or CIDR blocks.

Note

For Cloud Platform Enterprise, the bandwidth on the load balancer maxes out at around 50Mbps. On tests primarily hitting several pages with anonymous traffic, that may be the cap for data. If more bandwidth is needed, you will need an elastic load balancer that will route traffic in a round-robin to the available load balancers, which effectively multiplies the available bandwidth. This differs from the normal configuration where the secondary balancer idles awaiting the failure of the primary.

Before starting a load test

A load test is only effective if you are fully prepared. Use the following recommendations to help you prepare for your load test:

Note

A load test should mirror the anonymous and authenticated traffic percentages, to ensure the application stack can handle the load. Testing anonymous traffic on a website using authenticated users will give inaccurate results. Applications with more than 5% authenticated and non-cacheable traffic should have a load test targeting the most common use cases.

  • Be sure your application is ready: Be sure Drupal is ready for a load test by addressing any outstanding items from the Cloud Platform prelaunch checklist.
  • Develop a test plan: A load test plan is an essential component of a successful load test. The time it takes to configure a robust and meaningful load test increases with the variables affecting performance for an application. A load test plan should take into account the following variables:
    • How many applications will be tested? Are there various applications? Are there several applications on the same infrastructure? Are you using various domains with Domain Access?
    • How many subscriber roles will be tested? You may have several anonymous, comment-only users and editors.
    • Are you testing various languages? Multilingual implementations often have big implications.
    • What are the kinds of tasks each user role will be expected to carry out?
    • What is the workflow and what pages will be involved in navigating those tasks?
    • Have you created a list of form submissions to be mimicked?
    • Have you considered asynchronous JavaScript requests? Applications using AJAX often reduce, but never eliminate, performance issues.
    • Have you investigated your cache-clearing frequency? How does the application respond under load when caches clear or pages expire?
    • Have you developed specialized planning for applications using large amounts of JavaScript (for example, for presentations)?
  • Determine your test goals: If you don’t have concrete goals, you can’t determine if a load test is successful. Here are some examples of goal sets for testing:
    • Government website: 500 concurrent users “baseline test.” Find the system breakpoint by loading up to 500 concurrent users over 15 minutes and monitoring user and system metrics.
    • Entertainment news website: This test was designed to identify any performance bottlenecks in the application. The goal was to ramp up to 1,000 users and confirm the database bottleneck identified in the previous test was resolved.
    • Political campaign: Analyze the application performance against the environment in the following scenarios: S01, S02, S03, S04 and S05 with 10,000 users and a 40-minute ramp.
      • S01: Web Browser (70% of load)
      • S02: Web Donate 1 (7.5% of load)
      • S03: Web Donate 2 (7.5% of load)
      • S04: Web Petition (7.5% of load)
      • S05: Web Register (7.5% of load)
    • Retail chain: Analyze the application performance in the following scenarios: A, B, C, D, E, and F with 2,500 users and a 40-minute ramp. Use three different locations to generate the load: US East (Virginia), US West (Northern California), and London. Indicate that the user had a local_store cookie set to a random store location when first entering the application. This is designed to mimic a user returning to the application after selecting a default store.
      • Scenario A, Scenario A Cookie (30% of the load)
      • Scenario B, Scenario B Cookie (30% of the load)
      • Scenario C, Scenario C Cookie (20% of the load)
      • Scenario D, Scenario D Cookie (1% of the load)
      • Scenario E, Scenario E Cookie (8% of the load)
      • Scenario F, Scenario F Cookie (11% of the load)

Load testing recommendations

Load testing is the responsibility of the subscriber. Subscribers can engage Acquia Professional Services for a performance audit, which is a week-long code examination geared specifically for performance and scalability. After your analysis has provided the items that can be adjusted to improve performance, you can also engage Professional Services to make those technical adjustments. If you have a Technical Account Manager (TAM), you can request suggestions for how to best test the application or for some post-testing analysis.

What Acquia needs to know

Before you begin testing, the Acquia Support team needs to know the following information:

  • Exact start and end dates and times (including timezone) of the planned testing
  • Individual originating IP addresses conducting the testing
  • Expected methodologies and specific tools to be used in the process of the testing
  • Contact information for any third party conducting the testing (if being done by a third party)

After you have collected the required information, contact Acquia Support to create a ticket, and include this information. Be sure to notify the Support team at least two business days in advance of your testing.

Note

If you start a test without notifying Acquia Support and the test generates enough load, the Cloud Platform platform will treat the test as a presumed attack and will block it. You will then be asked to make arrangements to put a dedicated test balancer in place for the test. This takes at least two business days to arrange.

Acquia Support will engage other internal teams to prepare for your tests, as necessary.

Do-it-yourself testing

You can outline and set up a testing suite on your own using widely available tools. For example, you can use a service like BlazeMeter (which allows up to 40 free tests) to configure your load test plan using JMeter.

You can test the JMeter plan locally (with looping off and only one user per scenario). If everything is working, fill in the desired number of users, enable forever looping, and upload the plan to BlazeMeter for testing.

When load testing with BlazeMeter, you must start one or more BlazeMeter infrastructure depending on how much traffic you intend to receive (which will incur an extra cost from BlazeMeter). A test needs one BlazeMeter large infrastructure per 1MM (1 million page-views/month) expected traffic.

Pointing load test traffic to Acquia

You can’t use the Acquia load test IP directly. You must route traffic for a domain in the Acquia Prod environment to the load test IP through public DNS or through a HOSTS entry. You can use the Acquia default domain, or any domain of your choosing that’s been added to the Domains list for the Prod environment in the Cloud Platform dashboard. Blazemeter provides a HOSTS override feature directly from the test dashboard. You can add an IP and domain, and your test traffic will use the designated mapping without needing a public DNS rule, see Blazemeter: DNS Override.

Creating a load test script

If using a JMeter-based load test platform, you’ll need a jmx file that is a scripted representation of the load test scenario. The jmx file can be created using JMeter, by installing and configuring the Blazemeter Drupal contributed module on the website.

Calculating load test volume

An important aspect of load testing is ensuring the load test traffic volume is as exact as possible. The following Blazemeter document covers calculating hits per second, see Blazemeter: Calculating Hits Per Second.

Acquia strongly discourages compensating for a lower number of available concurrent users with a greater request rate. For various reasons, this approach yields an invalid test result. If the free Blazemeter offering doesn’t meet your needs, you can upgrade the Blazemeter subscription, or use another load generation tool that can support the desired traffic volume.

Blazemeter error rates and keep-alive

If using Blazemeter, it’s important to note if a page contains resources that timeout, this can cause a high error rate in Blazemeter reports unless use_keepalive values in the jmx file are converted from true to false using the following code:

<boolProp name="HTTPSampler.use_keepalive">false</boolProp>

Often, the actual request is returned as expected from the Acquia infrastructure. Setting the value to false will give a better picture of the actual error rate from the website.

53 State Street, 10th Floor
Boston, MA 02109
United States
Phone: 888-922-7842