Performance Testing AEM: ToughDay2


 One of the most important tests you can run before launching your new Adobe Experience Manager (AEM) site or deploying large changes to an existing site, is running a performance test against your environment(s). A properly run performance test should tell you whether your new site will perform as expected once public traffic starts flowing to it or if there will be issues that are not accounted for.

I usually recommend if you have an internal team that is skilled at performance tests you should have your internal team run the performance tests or consider a 3rd party that specializes in website testing.  This can help keep the results objective and ensure accurate testing.

However, sometimes there isn't an internal team to conduct the performance tests and you may wish to hold costs down or in the interest of time perform the tests yourself. 

 

What is ToughDay2?

Toughday2 is the successor to Toughday, a multi-threaded Java application that helps you stress test your AEM environments(s). Toughday2 is provided by Adobe that was created exclusively for stress testing Adobe Experience Manager. The project source is available on github for those that wish to build from source or you can grab the pre-built binaries from the Adobe repository.   The thing that makes Toughday2 unique is it was designed specifically to test AEM environments, both publish and author instances. It can easily simulate 100 or more authors logging in, uploading assets, creating and publishing pages, etc. This can be a pain point for most performance testing tools as they are usually designed to test the public part of your website not the authoring instance.   Toughday2 out-of-the-box contains a few default test suites that do a good job of testing, but unless you are just getting used to the tool you'll want to customize the tests and maybe write a few of your own.    

What You Need

 

  • Access to an AEM environment
  • A test plan
  • Somewhere to run the tests from. If these tests will be long running it would be best to run them from a server so you can execute the plan and review the results later.
  • The toughday2.jar file

   

Creating the Configuration

While you can run toughday2 and provide all the options from the command-line I highly recommend creating a configuration file, this will help ensure consistency between runs, you can add and customize multiple tests and even use the config as a template for other projects.   The configuration file uses YAML syntax, if you have never used yaml before I recommend reading up on it a bit beforehand. The syntax doesn't take long to get the hang of and you can be up and running in an hour or less if you've never used yaml before.  To make things easy we will create our file "toughday2.yaml" next to the toughday2.jar file we downloaded. 

  Directory listing of toughday2 files  

 

Adobe provides some descent documentation of usage on their website, but unfortunately it doesn't really cover everything. Using the website documentation along with the `--help` should give you enough information to create the test(s) you need. Below is an example configuration that will only test the publish instance(s) and specifically test the homepage and the about-us.html page.   When trying to decide what to test I always recommend at a minimum you should test:

  • The home page, this is usually where everyone lands so it will see the most traffic on your site.
  • A 'light' page and what I mean by that is one that is not very complex maybe contains an image or two and some text.
  • At least 1 complex page ideally this will be a page that contain some dynamic logic, videos, third-part integrations, etc.

The idea between the last two points are we want to be able to identify the type of experience someone will have on our site but also determine where our bottlenecks may be and how we can avoid them or improve pages that contain a lot of moving parts.

 

Toughday2.yaml

globals:
  suite: publish
  port: 443
  host: dev.test.mydomain.com
  installsamplecontent: false
  protocol: https
  duration: 1h
  timeout: 180
  dryrun: false
  hostvalidationenabled: true
runmode:
  type : normal
  waittime : 300
  concurrency : 200
publishmode:
  type : intervals
tests:
  - add: GetTest
    properties:
      path: /
      name: HomePage
  - config: Get1
    properties:
      name: About Us
      path: /en-us/about-us.html

 

Most of the configuration above is pretty self-explanatory, under the tests I've added a new test for the homepage and provided the necessary properties. Because Toughday2 contains a few basic test, one of those being 'Get1', I've provided an alternate configuration to that test. You can use '- add' to add as many additional tests you would like to test as much of the site you wish.

Now that we have our config file we are ready to run it. If this is a live site I highly recommend doing this at an off-peak time so you don't negatively impact your web users.

java -jar toughday2.jar --configfile=toughday2.yaml

Thats all there is to it! Once run you should see a display start collecting data about the tests being run. If your not sure what this data is tell you I recommend reading the Adobe documentation on test output and logs.

How do you rate this article?

1



Unofficial AEM DevOps
Unofficial AEM DevOps

A space to share my DevOps and Adobe Experience Manager (AEM) related experiences that I have gained over the years.

Send a $0.01 microtip in crypto to the author, and earn yourself as you read!

20% to author / 80% to me.
We pay the tips from our rewards pool.