Performance Optimization

Category: computer / software Date‌: 19 1401, 23:13 Author: a Views: 64

A key issue is the time your website takes to respond to visitor requests. Although this value will vary for each request, an average target value can be defined. Once this value is proven to be both achievable and maintainable, it can be used to monitor the performance of the website and indicate the development of potential problems.

The response times you will be aiming for will be different on the author and publish environments, reflecting the different characteristics of the target audience:

Author Environment
This environment is used by authors entering, and updating content. It must cater for a small number of users who each generate a high number of performance intensive requests when updating content pages and the individual elements on those pages.

Publish Environment
This environment contains content which you make available to your users. Here the number of requests is even greater and the speed is just as vital, but since the nature of the requests is less dynamic, additional performance enhancing mechanisms can be applied; such as caching the content or load-balancing.

Performance Optimization Methodology
A performance optimization methodology for AEM projects can be summed up in five very simple rules that can be followed to avoid performance issues from the start:

Planning for Optimization
Simulate Reality
Establish Solid Goals
Stay Relevant
Agile Iteration Cycles
These rules, to a large degree, apply to web projects in general, and are relevant to project managers and system administrators to ensure that their projects will not face performance challenges when launch time comes.

Planning for Optimization

Around 10% of the project effort should be planned for the performance optimization phase. Of course, the actual performance optimization requirements will depend on the level of complexity of a project and the experience of the development team. While your project may (ultimately) not require all of the allocated time, it is good practice to always plan for performance optimization in the suggested region.

Whenever possible, a project should first be soft-launched to a limited audience in order to gather real-life experience and perform further optimizations, without the additional pressure that follows a full announcement.

Once you are “live”, performance optimization is not over. This is the point in time when you experience the “real” load on your system. It is important to plan for additional adjustments after the launch.

Since your system load changes and the performance profiles of your system shifts over time, a performance “tune-up” or “health-check” should be scheduled at 6-12 months intervals.

Simulate Reality

If you go live with a website and find out after the launch that you run into performance issues there is only one reason for that: Your load and performance tests did not simulate reality closely enough.

Simulating reality is difficult and how much effort you will reasonably want to invest into getting “real” depends on the nature of your project. “Real” means not just “real code” and “real traffic”, but also “real content”, especially regarding content size and structure. Keep in mind that your templates may behave completely different depending on the size and structure of the repository.

Establish Solid Goals

The importance of properly establishing performance goals is not to be underestimated. Often, once people become focused on specific performance goals it is very hard to change these goals afterwards, even if they are based on wild assumptions.

Establishing good, solid performance goals is really one of the trickiest areas. It is often best to collect real life logs and benchmarks from a comparable website (for example the new website’s predecessor).

Stay Relevant

It is important to optimize one bottleneck at a time. If you try to do things in parallel without validating the impact of the one optimization, you will lose track of which optimization measure actually helped.

Performance tuning is an iterative process that involves, measuring, analysis, optimization and validation until the goal is reached. In order to properly take this aspect into account, implement an agile validation process in the optimization phase rather than a more heavy-weight testing process after each iteration.

This largely means that the developer implementing the optimization should have a quick way to tell if the optimization has already reached the goal. This is valuable information, because when the goal is reached, optimization is over.

Basic Performance Guidelines
Generally speaking, keep your uncached html requests to less than 100ms. More specifically, the following may serve as a guideline:

70% of the requests for pages should be responded to in less than 100ms.
25% of the requests for pages should get a response within 100ms-300ms.
4% of the requests for pages should get a response within 300ms-500ms.
1% of the requests for pages should get a response within 500ms-1000ms.
No pages should respond slower than 1 second.
The above numbers assume the following conditions:

Measured on publish (no overheads as related to an authoring environment)
Measured on the server (no network overhead)
Not cached (no AEM output cache, no Dispatcher cache)
Only for complex items with many dependencies (HTML, JS, PDF, …)
No other load on the system
There are a certain number of issues that frequently contribute to performance problems. These mainly revolve around:

Dispatcher caching inefficiency
The use of queries in normal display templates.
JVM and OS level tuning do not usually lead to big leaps in performance and should therefore be performed at the very end of the optimization cycle.

The way a content repository is structured can impact performance as well. For best performance, the number of child nodes attached to individual nodes in a content repository should not exceed 1,000 (as a general rule).

Your best friends during a usual performance optimization exercise are:

The request.log
Component based timing
Last but not least a java profiler.
Performance when loading and editing Digital Assets
Due to the large volume of data involved when loading and editing digital assets, performance can become an issue.

Two things affect performance here:

CPU - multiple cores allow for smoother work when transcoding
Hard disk - parallel RAID disks achieve the same
To improve performance you can consider the following:

How many assets are going to be uploaded per day? A good estimate can be based on:
chlimage_1-77

The time frame in which edits will be made (typically the length of the working day, more for international operations).
The average size of images uploaded (and the size of renditions generated per image) in megabytes.
Determine the average data rate:
chlimage_1-78

80% of all edits will be made in 20% of the time, so in peak time you will have 4 times the average data rate. This is your performance goal.
Performance Monitoring
Performance (or the lack of it) is one of the first things that your users notice, so as with any application with a user interface, performance is of key importance. To optimize the performance of your AEM installation you need to monitor various attributes of the instance and its behavior.

For information about how to perform performance monitoring, see Monitoring Performance.

The problems that cause performance issues are often difficult to track down, even when their effects are easy to see.

A basic starting point is a good knowledge of your system when it is operating as normal. Unless you know how your environment “looks” and “behaves” when it is performing properly, it can be difficult to locate the problem when performance deteriorates. This means that you should spend some time investigating your system when it is running smoothly and ensure that collecting performance information is an ongoing task. This will provide you with a basis for comparison should the performance suffer.

The following diagram illustrates the path that a request for AEM content can take, and therefore the number of different elements which can impact the performance.

Related News


What’s Wrong With Measuring Developer Performance
What’s Wrong With Measuring Developer Performance

What’s Wrong With Measuring Developer Performance Developer performance is a

15.07.01 computer / software
What is Software Development?
What is Software Development?

People both inside and outside IT often ask what is software development. It

15.07.01 computer / software
History of Software Development: Brief Guide for Starting Developers
History of Software Development: Brief Guide for Starting Developers

The world has seen many innovations in computing—from housing large computer

15.07.01 computer / software
History
History

History Software maintenance and systems evolution were first studied by Meir

15.07.01 computer / software
18 Tips for Website Performance Optimization
18 Tips for Website Performance Optimization

18 Tips for Website Performance Optimization Website performance optimization

15.07.01 computer / software
Apply basic performance optimization in Finance and Operations apps
Apply basic performance optimization in Finance and Operations apps

Apply basic performance optimization in Finance and Operations apps By

15.07.01 computer / software

close