Performance Troubleshooting

During the initial development phase of a website, not much attention is given to the performance of website i.e. how website will respond to million of requests. Performance means the time your website takes to respond to visitor’s request. But in the later stages of implementation you need to optimize the website to maximize the performance goals.In this blog, we will discuss some measures 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.

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

  2. Simulate Reality

    After the launch of 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.

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

  4. Stay Relevant

    Only optimize one things 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.

  5. Agile Iteration Cycles

    Performance tuning is an iterative process that involves, measuring, analysis, optimization and validation until the goal is reached.

Page Loading Time
  1. 70% of the requests for pages should be responded to in less than 100ms.
  2. 25% of the requests for pages should get a response within 100ms-300ms.
  3. 4% of the requests for pages should get a response within 300ms-500ms.
  4. 1% of the requests for pages should get a response within 500ms-1000ms.
  5. No pages should respond slower than 1 second.
Performance Guidelines
  1. Mostly dispatcher caching inefficiency and use of queries in normal display templates leads to performance issues.
  2. 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 Monitoring

To optimize the performance, you need to monitor various attributes of the instance and its behavior.

  1. Backup plan and Disaster recovery plan should be there.
  2. An error tracking system(like bugZilla, JIRA) should be available for reporting problems.
  3. File systems, Log files and Replication agents should be monitored.
  4. Regularly purge workflow instances.
INTERPRETING THE REQUEST.LOG
  1. To analyze a bigger request.log, it is recommended to use rlog.jar which allows you to sort and filter according to response times.
  2. AEM includes various helper tools located in : <cq-installation-dir>/crx-quickstart/opt/helpers
  3. 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
  1. To open request.log in terminal : less request.log or more request.log
  2. 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 impossble 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 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 URI 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 web server). 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 – l

    Let this number be 26855.

  • Therefore, publisher cache ratio = (58959 – 26855) / 58959 = 54.5%

Thus, you can apply performance enhancing mechanisms to your website like caching the content, measuring page load time before its launch to reduce the response time of your website and thus providing a good user experience.

Thank You for enjoying this blog !

0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *