During the initial development phase of a website, not much attention is given to the performance of a website i.e. how the website will respond to millions of requests. Performance means the time your website takes to respond to visitors’ requests. In the later stages of implementation you need to optimize the website to maximize the performance goals. In this article, we will discuss some measures to optimize your AEM website, which is to increase the page load time so as to provide good experience to users.
Performance Optimization Methodology
Five rules that should be followed to avoid performance issues in AEM sites.
Planning for Optimization
A project should first be soft-launched to a limited audience in order to gather real-life experience. When the website is live, it is the time when you experience real load on your system.
Simulate Reality
After the launch of your website, if there are some performance issues, it means load and performance tests did not simulate reality closely enough. “Real” means real traffic, real content size and real code.
Establish Solid Goals
Establishing good performance goals is a tough task. It is often best to collect real life logs and benchmarks from a comparable website.
Stay Relevant
Only optimize one thing at a time. If you try to do things in parallel without validating the impact of the one optimization, later it will be difficult to figure out which optimization actually helped.
Agile Iteration Cycles
Performance tuning is an iterative process that involves measuring, analysis, optimization and validation until the goal is reached.
Page Loading Time
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.
Performance Guidelines
Mostly dispatcher caching inefficiency and use of queries in normal display templates leads to performance issues.
JVM and OS level tuning does not impact the performance much. Therefore, it should be performed at the very end of the optimization cycle.
Performance Optimization Methodology
Five rules that should be followed to avoid performance issues in AEM sites.
Planning for Optimization
A project should first be soft-launched to a limited audience in order to gather real-life experience. When the website is live, it is the time when you experience real load on your system.
Simulate Reality
After the launch of your website, if there are some performance issues, it means load and performance tests did not simulate reality closely enough. “Real” means real traffic, real content size and real code.
Establish Solid Goals
Establishing good performance goals is a tough task. It is often best to collect real life logs and benchmarks from a comparable website.
Stay Relevant
Only optimize one thing at a time. If you try to do things in parallel without validating the impact of the one optimization, later it will be difficult to figure out which optimization actually helped.
Agile Iteration Cycles
Performance tuning is an iterative process that involves measuring, analysis, optimization and validation until the goal is reached.
Page Loading Time
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.
Performance Guidelines
Mostly dispatcher caching inefficiency and use of queries in normal display templates leads to performance issues.
JVM and OS level tuning does not impact the performance much. Therefore, it should be performed at the very end of the optimization cycle.
AEM Website Performance Monitoring
To optimize your AEM website performance, you need to monitor various attributes of the instance and its behavior.
Backup plan and Disaster recovery plan should be there.
An error tracking system(like bugZilla, JIRA) should be available for reporting problems.
File systems, Log files and Replication agents should be monitored.
Regularly purge workflow instances.
INTERPRETING THE REQUEST.LOG
To analyze a bigger request.log, it is recommended to use rlog.jar which allows you to sort and filter according to response times.
AEM includes various helper tools located in : <cq-installation-dir>/crx-quickstart/opt/helpers
One of these, rlog.jar, can be used to quickly sort request.log so that requests are displayed by duration, from longest to shortest time.
Basic Commands
To open request.log in terminal : less request.log or more request.log
java -jar ../opt/helopers/rlog.jar -xdev request.log | less
This command tells you the number of requests parsed. Requests are sorted from longest to shortest time.
By looking at the result, we can figure out “/cust1.cust.html?page text/html” is not cached
because its request is coming to the server again and again.
“/companyservice/contact.html text/html” is a cacheable page. Even though it is cacheable, it is taking 44s.
Non-cacheable pages are taking a lot of time, either publisher is non-responsive or these pages are requesting something from backend server and backend server is down.
3. Now we will see how many times “/companyservice/contact.html text/html” page is rendered.
java -jar ../opt/helpers/rlog.jar -xdev request.log | grep “/companyservice/contact.html ” | wc -l
This cacheable page is rendered 122 times a day, which is a huge number. It is also impossible to invalidate cache 122 times a day. Therefore, there is some issue with caching configuration.
4. Here we are piping the result into a text file ‘demo.txt’. Now, we can sort the data by date and get to know what is actually happening on publisher.
java -jar ../opt/helpers/rlog.jar -xdev request.log > demo.txt
Calculating Cache Ratio
1. Cache ratio means how many requests that come to your system are handled by cache.
2. Dispatcher Cache Ratio
(Total Number of Requests – Number of Requests on Publisher )/ Total Number of Requests
Remember if you don’t have a 1:1 publisher/dispatcher pairing, you will need to add requests from all dispatchers and publishers together to get an accurate measurement
3. Publisher Cache Ratio
Total number of cacheable page request coming to the publisher
(Total Publisher Request – Total non-cacheable Requests) / Total Publisher Requests
4. Adobe Recommends a Cache Ratio of 90-95% for best performance.
5. The Dispatcher always requests the document directly from the AEM instance in the following cases:
If the HTTP method is not GET. Other common methods are POST for form data and HEAD for the HTTP header.
If the request URL contains a question mark “?”. This usually indicates a dynamic page, such as a search result, which does not need to be cached.
The file extension is missing. The web server needs the extension to determine the document type (the MIME-type).
6. Calculating Dispatcher Cache Ratio Using Access log and Request log
wc -l access.log(To get total number of requests to webserver). Let this number be 129491
java -jar ../opt/helpers/rlog.jar -xdev request.log | less(To get number of requests on publisher). Let this number be 58959
Therefore, dispatcher cache ratio =(129491 – 58959) / 129491 = 54.5 %
7. Calculating Publisher Cache Ratio
java -jar ../opt/helpers/rlog.jar -xdev request.log | less(To get number of requests on publisher). Let this number be 58959.
From this we will pull out the requests which are not cacheable using :java -jar ../opt/helpers//rlog.jar -xdev request..log | grep -Ev “\?|login|POST” | wc – lLet this number be 26855.
Therefore, publisher cache ratio = (58959 – 26855) / 58959 = 54.5%
Thus, you can apply some performance-enhancing mechanisms to optimize your AEM website like caching the content, measuring page load time before its launch to reduce the response time of your website and thus provide a good user experience.
To optimize your AEM website performance, you need to monitor various attributes of the instance and its behavior.
Backup plan and Disaster recovery plan should be there.
An error tracking system(like bugZilla, JIRA) should be available for reporting problems.
File systems, Log files and Replication agents should be monitored.
Regularly purge workflow instances.
INTERPRETING THE REQUEST.LOG
To analyze a bigger request.log, it is recommended to use rlog.jar which allows you to sort and filter according to response times.
AEM includes various helper tools located in : <cq-installation-dir>/crx-quickstart/opt/helpers
One of these, rlog.jar, can be used to quickly sort request.log so that requests are displayed by duration, from longest to shortest time.
Basic Commands
To open request.log in terminal : less request.log or more request.log
java -jar ../opt/helopers/rlog.jar -xdev request.log | less
This command tells you the number of requests parsed. Requests are sorted from longest to shortest time.
By looking at the result, we can figure out “/cust1.cust.html?page text/html” is not cached
because its request is coming to the server again and again.
“/companyservice/contact.html text/html” is a cacheable page. Even though it is cacheable, it is taking 44s.
Non-cacheable pages are taking a lot of time, either publisher is non-responsive or these pages are requesting something from backend server and backend server is down.
3. Now we will see how many times “/companyservice/contact.html text/html” page is rendered.
java -jar ../opt/helpers/rlog.jar -xdev request.log | grep “/companyservice/contact.html ” | wc -l
This cacheable page is rendered 122 times a day, which is a huge number. It is also impossible to invalidate cache 122 times a day. Therefore, there is some issue with caching configuration.
4. Here we are piping the result into a text file ‘demo.txt’. Now, we can sort the data by date and get to know what is actually happening on publisher.
java -jar ../opt/helpers/rlog.jar -xdev request.log > demo.txt
Calculating Cache Ratio
1. Cache ratio means how many requests that come to your system are handled by cache.
2. Dispatcher Cache Ratio
(Total Number of Requests – Number of Requests on Publisher )/ Total Number of Requests
Remember if you don’t have a 1:1 publisher/dispatcher pairing, you will need to add requests from all dispatchers and publishers together to get an accurate measurement
3. Publisher Cache Ratio
Total number of cacheable page request coming to the publisher
(Total Publisher Request – Total non-cacheable Requests) / Total Publisher Requests
4. Adobe Recommends a Cache Ratio of 90-95% for best performance.
5. The Dispatcher always requests the document directly from the AEM instance in the following cases:
If the HTTP method is not GET. Other common methods are POST for form data and HEAD for the HTTP header.
If the request URL contains a question mark “?”. This usually indicates a dynamic page, such as a search result, which does not need to be cached.
The file extension is missing. The web server needs the extension to determine the document type (the MIME-type).
6. Calculating Dispatcher Cache Ratio Using Access log and Request log
wc -l access.log(To get total number of requests to webserver). Let this number be 129491
java -jar ../opt/helpers/rlog.jar -xdev request.log | less(To get number of requests on publisher). Let this number be 58959
Therefore, dispatcher cache ratio =(129491 – 58959) / 129491 = 54.5 %
7. Calculating Publisher Cache Ratio
java -jar ../opt/helpers/rlog.jar -xdev request.log | less(To get number of requests on publisher). Let this number be 58959.
From this we will pull out the requests which are not cacheable using :java -jar ../opt/helpers//rlog.jar -xdev request..log | grep -Ev “\?|login|POST” | wc – lLet this number be 26855.
Therefore, publisher cache ratio = (58959 – 26855) / 58959 = 54.5%
Thus, you can apply some performance-enhancing mechanisms to optimize your AEM website like caching the content, measuring page load time before its launch to reduce the response time of your website and thus provide a good user experience.
No comments:
Post a Comment
If you have any doubts or questions, please let us know.