Load testing requires significant extra preparation and resources even if you have experience evaluating your application’s performance using security and penetration testing vulnerability scans. For information about Cloud Platform subscription and infrastructure requirements, see Load testing requirements.
A load test is effective only if you are fully prepared. To plan effectively for your load test, perform the steps listed on this page.
Prepare your application
Ensure that your application is ready. Confirm that 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 do not have concrete goals, you cannot determine if a load test is successful. The following are the 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 is to ramp up to 1,000 users and confirm that the database bottleneck identified in the previous test is 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)
Replicate traffic percentages
A load test must mirror the anonymous and authenticated traffic percentages. This ensures that the application stack can handle the load. Testing anonymous traffic on a website by using authenticated users can give inaccurate results.
Notify Acquia Support
Before you begin testing, you must provide the following information to Acquia Support:
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, create a Support ticket. Be sure to notify the Support team at least 2 business days in advance of your testing.
Note
If you start a test without notifying Acquia Support and the test generates more than the permissible load, Cloud Platform treats the test as a presumed attack and blocks it. You are then asked to make arrangements to put a dedicated test balancer in place for the test.
Acquia Support will engage other internal teams to prepare for your tests, as necessary.
Planning a load test
Load testing requires significant extra preparation and resources even if you have experience evaluating your application’s performance using security and penetration testing vulnerability scans. For information about Cloud Platform subscription and infrastructure requirements, see Load testing requirements.
A load test is effective only if you are fully prepared. To plan effectively for your load test, perform the steps listed on this page.
Prepare your application
Ensure that your application is ready. Confirm that 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 do not have concrete goals, you cannot determine if a load test is successful. The following are the 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 is to ramp up to 1,000 users and confirm that the database bottleneck identified in the previous test is 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)
Replicate traffic percentages
A load test must mirror the anonymous and authenticated traffic percentages. This ensures that the application stack can handle the load. Testing anonymous traffic on a website by using authenticated users can give inaccurate results.
Notify Acquia Support
Before you begin testing, you must provide the following information to Acquia Support:
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, create a Support ticket. Be sure to notify the Support team at least 2 business days in advance of your testing.
Note
If you start a test without notifying Acquia Support and the test generates more than the permissible load, Cloud Platform treats the test as a presumed attack and blocks it. You are then asked to make arrangements to put a dedicated test balancer in place for the test.
Acquia Support will engage other internal teams to prepare for your tests, as necessary.
Did not find what you were looking for?
If this content did not answer your questions, try searching or contacting our support team for further assistance.
Did not find what you were looking for?
If this content did not answer your questions, try searching or contacting our support team for further assistance.
Cloud Platform