Stress test the AEM capability using Tough day 2

What is 'Tough day 2'?
In real scenarios, we need to stress test the AEM to find out its limits. Tough day 2 is a tool provided by Adobe to stress test AEM instances.
It has a default test suite or can be customized as per the needs to run various stress tests in AEM.

How do we get the Tough Day 2 Application?
We can get it from Adobe Repository

How to run Tough Day 2?
We need to run the Tough Day 2 jar using the below command; where the localhost is the host where AEM is running.

java -jar toughday2.jar --host=localhost

How to get help?
To enable the Help, run Tough day 2 using below command,
java -jar toughday2.jar --help_full

What are the default test options available for Tough day 2?
Some of the default cases are given below,
1) Getting the Home page
2) Triggering the queries in the Query builder
3) Delete the assets from DAM
4) Create pages
5) Create live copies and run roll outs

Can we customize Tough Day 2?
Yes as mentioned previously, we have a complete customization option here. We can do it by either providing command line parameters or YAML configurations. Command-line has the highest priority, which means, it can override the configuration files or default parameters.
Configuration files have the second priority, which can override the default configurations.
Remember this, configuration files are used for large custom suites to make it easier.

What are all the various run modes available in Tough Day 2?
1) Normal: This generates a constant number of threads. It has 2 params
a) Concurrency
b) wait time

2) Constant Load: This generates a constant number of started test executions.
How do we analyze Test Day 2 Output?
The output of Test Day 2 consists of logs and test metrics(9 of them).

Test Metrics
The test metrics are available in CSV (CSVPublisher) and in the console (ConsolePublisher ) form.

Logs
The logs are also created under the same folder of Tough Day 2 installation.
2 Files are created,
a) generic(toughday.log)- all generic & global messages
b) custom(toughday_<testname>.log) - related to our specific test

Do we need a load test in the AEM Authoring instance?
In usual scenarios, the Author's performance has been less of a problem in most cases. But the number of concurrent users and the size of the assets are the biggest factors in sizing the author. The general practice is load-test content authoring workloads only when a) the number of content authors is high (>50) AND b) they use AEM ASSETS.

The load test is done using Tools like JMeter(Author/Publish instance in our Jenkins pipeline), LoadRunner, etc. Recommendation is always to test with production size content! AEM author will not have less number of pages w.r.t production( For e.g. 10 pages vs 100.000+ pages are a big change to compare)

Summary:
The test suite comprises of 85% read and 15% write. When we install and run Tough Day 2, it installs all the content packages, which can be avoided by passing parameters while load run.
The parameters list can be found here for AEM 6.5

Since Tough Day 2 once run cannot clean up the things from AEM by itself, it is always recommended to run Tough day on a cloned AEM instance.