This page provides general guidelines on how to optimize the performance of your AEM deployment. If you are new to AEM, please go over the following pages before you start reading the performance guidelines:

Illustrated below are the deployment options available for AEM (scroll to view all the options):

AEM

Product

Topology

Operating System

Application Server

JRE

Security

Micro Kernel

Datastore

Indexing

Web Server

Browser

Marketing Cloud

Sites

Non-HA

Windows

CQSE

Oracle

LDAP

Tar

Segment

Property

Apache

Edge

Target

Assets

Publish-HA

Solaris

WebLogic

IBM

SAML

MongoDB

File

Lucene

IIS

IE

Analytics

Communities

Author-CS

Red Hat

WebSphere

HP

Oauth

RDB/Oracle

S3

Solr

iPlanet

FireFox

Campaign

Forms

Author-Offload

HP-UX

Tomcat

RDB/DB2

MongoDB

Chrome

Social

Mobile

Author-Cluster

IBM AIX

JBoss

RDB/MySQL

RDBMS

Safari

Audience

Multi-site

ASRP

SUSE

RDB/SQLServer

Assets

Commerce

MSRP

Apple OS

Activation

Dynamic Media

JSRP

Mobile

Brand Portal

J2E

AoD

LiveFyre

Screens

Doc Security

Process Mgt

Desktop App

Huomautus:

The performance guidelines apply mainly to AEM Sites.

When to Use the Performance Guidelines

You should use the performance guidelines in the following situations:

First time deployment: When planning to deploy AEM Sites or Assets for the first time, it is important to understand the options available when configuring the Micro Kernel, Node Store, and Data Store (compared to the default settings). For example, changing the default settings of the Data Store for TarMK to File Data Store.

Upgrading to a new version: When upgrading to a new version, it is important to understand the performance differences compared to the running environment. For example, upgrading from AEM 6.1 to 6.2, or from AEM 6.0 CRX2 to 6.2 OAK.

Response time is slow: When the selected Nodestore architecture is not meeting your requirements, it is important to understand the performance differences compared to other topology options. For example, deploying TarMK instead of MongoMK, or using a File Data Sore instead of an Amazon S3 Shared Data Store.

Adding more authors: When the recommended TarMK topology is not meeting the performance requirements and upsizing the Author node has reached the maximum capacity available, it is important to understand the performance differences compared to using MongoMK with three or more Author nodes. For example, deploying MongoMK instead of TarMK.

Adding more content: When the recommended Data Store architecture is not meeting your requirements, it’s important to understand the performance differences compared to other Data Store options. Example: using the Amazon S3 Data Store instead of a File Data Store.

Introduction

This chapter gives a general overview of the AEM architecture and its most important components. It also provides development guidelines and describes the testing scenarios used in the TarMK and MongoMK benchmark tests.

The AEM Platform

The AEM Architecture

There are three important building blocks to an AEM deployment. The Author Instance which is used by content authors, editors, and approvers to create and review content. When the content is approved, it is published to a second instance type named the Publish Instance from where it is accessed by the end users. The third building block is the Dispatcher which is a module that handles caching and URL filtering and is installed on the webserver. For additional information about the AEM architecture, see Typical Deployment Scenarios.

Micro Kernels

Micro Kernels act as persistence managers in AEM. There are three types of Micro Kernels used with AEM: TarMK, MongoDB, and Relational Database (under restricted support). Choosing one to fit your needs depends on the purpose of your instance and the deployment type you are considering. For additional information about Micro Kernels, see the Recommended Deployments page.

Nodestore

In AEM, binary data can be stored independently from content nodes. The location where the binary data is stored is referred to as the Data Store, while the location of the content nodes and properties is called the Node Store.

Huomautus:

Adobe recommends TarMK to be the default persistence technology used by customers for both the AEM Author and the Publish instances.

Varoitus:

The Relational Database Micro Kernel is under restricted support. Contact Adobe Customer Care before using this type of Micro Kernel.

Data Store

When dealing with large number of binaries, it is recommended that an external data store be used instead of the default node stores in order to maximize performance. For example, if your project requires a large number of media assets, storing them under the File or S3 Data Store will make accessing them faster than storing them directly inside a MongoDB.

Benchmark Scenarios

Huomautus:

All the benchmark tests displayed on this page have been performed in a laboratory setting.

The testing scenarios detailed below are used for the benchmark sections of the TarMK, MongoMk and TarMK vs MongoMk chapters. To see which scenario was used for a particular benchmark test, read the Scenario field from the Technical Specifications table.

TarMK

This chapter gives general performance guidelines for TarMK specifying the minimum architecture requirements and the settings configuration. Benchmark tests are also provided for further clarification.

Adobe recommends TarMK to be the default persistence technology used by customers in all deployment scenarios, for both the AEM Author and Publish instances.

This workflow manages XMP write-back to the original binary and sets the last modified date in JCR.

TarMK Performance Benchmark

Technical Specifications

The benchmark tests were performed on the following specifications:

Author Node

Server

Bare metal hardware (HP)

Operating System

RedHat Linux

CPU / Cores

Intel(R) Xeon(R) CPU E5-2407 @2.40GHz, 8 cores

RAM

32GB

Disk

Magnetic

Java

Oracle JRE Version 8

JVM Heap

16GB

Product

AEM 6.2

Nodestore

TarMK

Datastore

File DS

Scenario

Single Product: Assets / 30 concurrent threads

Performance Bechmark Results

Huomautus:

The numbers presented below have been normalized to 1 as the baseline and are not the actual throughput numbers.

MongoMK

The primary reason for choosing the MongoMK persistence backend over TarMK is to scale the instances horizontally. This means having two or more active author instances running at all times and using MongoDB as the persistence storage system. The need to run more than one author instance results generally from the fact that the CPU and memory capacity of a single server, supporting all concurrent authoring activities, is no longer sustainable.

MongoMK Minimum Architecture Guidelines

To establish good performance when using MongoMK, you should start from the following architecture:

Three Author instances

Two Publish instances

Three MongoDB instances

Two Dispatchers

Huomautus:

In production environments, MongoDB will always be used as a replica set with a primary and two secondaries. Reads and writes go to the primary and reads can go to the secondaries. If storage is not available, one of the secondaries can be replaced with an arbiter, but MongoDB replica sets must always be composed of an odd number of instances.

Huomautus:

Binary-less replication should be turned ON if the File Datastore is shared.

MongoMK Settings Guidelines

For good performance, you should follow the settings guidelines presented below. For instructions on how to change the settings, see this page.

Setting

Parameter

Value (default)

Description

Sling Job Queues

queue.maxparallel

Set value to half of the number of CPU cores.

By default the number of concurrent threads per job queue is equal to the number of CPU cores.

Granite Transient Workflow Queue

Max Parallel

Set value to half of the number of CPU cores.

JVM parameters

Doak.queryLimitInMemory

Doak.queryLimitReads

Dupdate.limit

Doak.fastQuerySize

Doak.mongo.maxQueryTimeMS

500000

100000

250000

True

60000

Add these JVM parameters in the AEM start script to prevent expansive queries from overloading the systems.

Performance Benchmark Results

Huomautus:

The numbers presented below have been normalized to 1 as the baseline and are not the actual throughput numbers.

TarMK vs MongoMK

The basic rule that needs to be taken into account when choosing between the two is that TarMK is designed for performance, while MongoMK is used for scalability. Adobe recommends TarMK to be the default persistence technology used by customers in all deployment scenarios, for both the AEM Author and Publish instances.

The primary reason for choosing the MongoMK persistence backend over TarMK is to scale the instances horizontally. This means having two or more active author instances running at all times and using MongoDB as the persistence storage system. The need to run more than one author instance generally results from the fact that the CPU and memory capacity of a single server, supporting all concurrent authoring activities, is no longer sustainable.

TarMK vs MongoMK Benchmarks

The numbers presented below have been normalized to 1 as the baseline and are not actual throughput numbers.

Scenario 1 Technical Specifications

Author OAK Node

MongoDB Node

Server

Bare metal hardware (HP)

Bare metal hardware (HP)

Operating System

RedHat Linux

RedHat Linux

CPU / Cores

Intel(R) Xeon(R) CPU E5-2407 @2.40GHz, 8 cores

Intel(R) Xeon(R) CPU E5-2407 @2.40GHz, 8 cores

RAM

32GB

32GB

Disk

Magnetic - >1k IOPS

Magnetic - >1k IOPS

Java

Oracle JRE Version 8

N/A

JVM Heap16GB

16GB

N/A

Product

AEM 6.2

MongoDB 3.2 WiredTiger

Nodestore

TarMK or MongoMK

N/A

Datastore

File DS

N/A

Scenario

Single Product: Assets / 30 concurrent threads per run

Scenario 1 Performance Benchmark Results

Scenario 2 Technical Specifications

Huomautus:

To enable the same number of Authors with MongoDB as with one TarMK system you need a cluster with two AEM nodes. A four node MongoDB cluster can handle 1.8 times the number of Authors than one TarMK instance. An eight node MongoDB cluster can handle 2.3 times the number of Authors than one TarMK instance.

Author TarMK Node

Author MongoMK Node

MongoDB Node

Server

AWS c3.8xlarge

AWS c3.8xlarge

AWS c3.8xlarge

Operating System

RedHat Linux

RedHat Linux

RedHat Linux

CPU / Cores

32

32

32

RAM

60GB

60GB

60GB

Disk

SSD – 10k IOPS

SSD – 10k IOPS

SSD – 10k IOPS

Java

Oracle JRE Version 8

Oracle JRE Version 8

N/A

JVM Heap16GB

30GB

30GB

N/A

Product

AEM 6.2

AEM 6.2

MongoDB 3.2 WiredTiger

Nodestore

TarMK

MongoMK

N/A

Datastore

File DS

File DS

N/A

Scenario

Vertical use case: Media / 2000 concurrent threads

Scenario 2 Performance Benchmark Results

Architecture Scalability Guidelines For AEM Sites and Assets

Summary of Performance Guidelines

The guidelines presented on this page can be summarized as follows:

TarMK with File Datastore is the recommended architecture for most customers:

Minimum topology: one Author instance, two Publish instances, two Dispatchers

Binary-less replication turned on if the File Datastore is shared

MongoMK with File Datastore is the recommended architecture for horizontal scalability of the Author tier:

Minimum topology: three Author instances, three MongoDB instances, two Publish instances, two Dispatchers

Binary-less replication turned on if the File Datastore is shared

Nodestore should be stored on the local disk, not a network attached storage (NAS)

Amazon S3 is the recommended datastore for a total volume of assets above 5TB

The Amazon S3 datastore is shared between the Author and Publish tier

Binary-less replication must be turned on

Datastore Garbage Collection requires a first run on all Author and Publish nodes, then a second run on Author

Custom index should be created in addition to the out of the box index based on most common searches

Lucene indexes should be used for the custom indexes

Customizing workflow can substantially improve the performance, for example, removing the video step in the “Update Asset” workflow, disabling listeners which are not used, etc.