CQ-OPS

Adobe Experience Manager (AEM) Operations
Blog by Jayan Kandathil that specializes in Adobe Experience Manager (CQ, now AEM) ops such as deployment architecture, server sizing, infrastructure, operations, cloud, performance etc.
  • October 15, 2012 4:00 pm

    A CQ DAM Performance Benchmark for Images and PDFs

    Adobe ships a performance testing tool and benchmark for CQ called “Tough Day" for customers to use.  It is documented here.  It can be downloaded here.

    Among the various tests it is capable of performing, there are a couple that are relevant to Digital Asset Manager (DAM) performance.

    Assuming that your current working directory contains toughday-5.5.jar, the following command will upload 1,000 112 KB 849px x 565px JPEG images to CQ DAM and report the elapsed time (about 4 minutes on a server with 8 CPU cores and solid state drives).

    java -Xmx2048m -Dhostname=yourcqserver.domain.com -Dport=4502 -DuploadImage.count=1000 -jar toughday-5.5.jar uploadImage

    Please note that the renditions workflows triggered by the ingestion of these images will last a lot longer than the reported elapsed time, especially if the server CPUs are under-powered.  At least two CPU cores are needed for a valid test.

    Created images are NOT deleted after the test.  They will be created under /content/dam/ with 50 images per folder with names such as /images1880.

    The following command will upload 1,000 556 KB PDF files to CQ DAM and report the elapsed time (about 3 minutes on a server with 8 CPU cores and solid state drives when Tough Day is run locally, about 6.5 minutes when Tough Day is run remotely on another machine, ping delay 1 ms, 1 hop).:

    java -Xmx2048m -Dhostname=yourcqserver.domain.com -Dport=4502 -DuploadPdf.count=1000 -jar toughday-5.5.jar uploadPdf

    Created PDF documents are NOT deleted after the test.  They will be created under /content/dam/ with 50 PDFs per folder with names such as /pdf7498.

    This operation is CPU-intensive - see screenshot of Windows Task Manager below:

    image

    If you get the following WARNING message in error.log (reached maximum number of queued asynchronous events):

    *WARN* [192.150.23.10 [1350325729654] POST /bin/wcmcommand HTTP/1.1] org.apache.jackrabbit.core.observation.ObservationDispatcher More than 200000 events in the queue java.lang.Exception: Stack Trace

    re-start CQ with the following additional JVM init argument in the start script:

    -Djackrabbit.maxQueuedEvents=1000000

    See this for more details.

    NOTE: The following command will run all of the “Tough Day” tests (for Web Content Management [WCM] as well as Digital Asset Management [DAM]):

    java -Xmx2048m -Dhostname=yourcqserver.domain.com -Dport=4502 -jar toughday-5.5.jar all

    On a server with 8 CPU cores and solid state drives (SSD), this complete test suite should finish in about 6 minutes (Tough Day running on same server - no network latency).  With Tough Day running remotely (thus incurring network overhead), it took 23 minutes on a server with 4 CPU cores and mechanical hard disks (HDD).

    On a desktop with 2 CPU cores and mechanical hard disks (HDD), this took about 14 minutes (Tough Day running on same server - no network latency).

    Essentially, if this particular test takes longer than 30 minutes on your server hardware, you should identify and address potential performance issues before deployment to production.