When to Use the Performance Guidelines

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. Especially 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 or Microsoft® Azure 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, understand the performance differences. Compare 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 is important to understand the performance differences compared to other Data Store options. Example: using the Amazon S3 or Microsoft® Azure 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 platform consists of the following components:

chlimage_1

For more information on the AEM platform, see What is AEM.

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.

chlimage_1-1

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 need 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.

chlimage_1-2

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.

NOTE
Adobe recommends TarMK to be the default persistence technology used by customers for both the AEM Author and the Publish instances.
CAUTION
The Relational Database Micro Kernel is under restricted support. Contact Adobe Customer Care before using this type of Micro Kernel.

chlimage_1-3

Data Store

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

For further details on the available configuration options, see Configuring Node and Data Stores.

NOTE
Adobe recommends that you choose the option of deploying AEM on Azure or Amazon Web Services (AWS) using Adobe Managed Services. Customers benefit from a team who has the experience and skills of deploying and operating AEM in these cloud computing environments. See additional documentation on Adobe Managed Services.
For recommendations on how to deploy AEM on Azure or AWS, outside of Adobe Managed Services, Adobe recommends working directly with the cloud provider. Or, work with one of Adobe’s partners that support the deployment of AEM in the cloud environment of your choice. The selected cloud provider or partner is responsible for the sizing specifications, design, and implementation of the architecture they are supporting to meet your specific performance, load, scalability, and security requirements.

See also the technical requirements page.

Search

Listed in this section are the custom index providers used with AEM. To know more about indexing, see Oak Queries and Indexing.

NOTE
For most deployments, Adobe recommends using the Lucene Index. Use Solr only for scalability in specialized and complex deployments.

chlimage_1-4

Development Guidelines

Develop for AEM aiming for performance and scalability. The following are best practices that you can follow:

DO

  • Apply separation of presentation, logic, and content
  • Use existing AEM APIs (ex: Sling) and tooling (ex: Replication)
  • Develop in the context of actual content
  • Develop for optimum cacheability
  • Minimize number of saves (ex: by using transient workflows)
  • Make sure that all HTTP end points are RESTful
  • Restrict the scope of JCR observation
  • Be mindful of asynchronous thread

DON’T

  • Do not use JCR APIs directly, if you can

  • Do not change /libs, but rather use overlays

  • Do not use queries wherever possible

  • Do not use Sling Bindings to get OSGi services in Java™ code, but rather use:

    • @Reference in a DS component
    • @Inject in a Sling Model
    • sling.getService() in a Sightly Use Class
    • sling.getService() in a JSP
    • a ServiceTracker
    • direct access to the OSGi service registry

For further details about developing on AEM, read Developing - The Basics. For additional best practices, see Development Best Practices.

Benchmark Scenarios

NOTE
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.

Single Product Scenario

AEM Assets:

  • User interactions: Browse Assets / Search Assets / Download Asset / Read Asset Metadata / Update Asset Metadata / Upload Asset / Run Upload Asset Workflow
  • Execution mode: concurrent users, single interaction per user

Mix Products Scenario

AEM Sites + Assets:

  • Sites user interactions: Read Article Page / Read Page / Create Paragraph / Edit Paragraph / Create Content Page / Activate Content Page / Author Search
  • Assets user interactions: Browse Assets / Search Assets / Download Asset / Read Asset Metadata / Update Asset Metadata / Upload Asset / Run Upload Asset Workflow
  • Execution mode: concurrent users, mixed interactions per user

Vertical Use Case Scenario

Media:

  • Read Article Page (27.4%), Read Page (10.9%), Create Session (2.6%), Activate Content Page (1.7%), Create Content Page (0.4%), Create Paragraph (4.3%), Edit Paragraph (0.9%), Image Component (0.9%), Browse Assets (20%), Read Asset Metadata (8.5%), Download Asset (4.2%), Search Asset (0.2%), Update Asset Metadata (2.4%), Upload Asset (1.2%), Browse Project (4.9%), Read Project (6.6%), Project Add Asset (1.2%), Project Add Site (1.2%), Create Project (0.1%), Author Search (0.4%)
  • Execution mode: concurrent users, mixed interactions per user