Expand my Community achievements bar.

Don’t miss the AEM Skill Exchange in SF on Nov 14—hear from industry leaders, learn best practices, and enhance your AEM strategy with practical tips.
SOLVED

pageinfo.json is taking time to load

Avatar

Level 2

Hi All.

I am facing one issue related to page load when I looked at the network logs it is pageinfo.json which is taking more than 15 sec to load. It is badly impacting page and workflow package load. Is there any way to tackle this issue. I am using AEM 6.0 SP2, oak 1.0.12. Are there any indexes we need to create for this? We have less than 100 groups and users. All are OOTB workflows only two custom workflows.

1 Accepted Solution

Avatar

Correct answer by
Employee Advisor

Hi,

I cannot say, what the problem is, the threaddump does not indicate the number of calls to MongoDB. If course latency is an issue (always). Maybe you can check the number of requests in mongodb.

Jörg

View solution in original post

13 Replies

Avatar

Employee Advisor

Hi,

can you share the details of such a request as show by the "recent requests" screen in the OSGI console (/system/console/requests)? It will give some more insights, where the problem can originate from.

Thanks,
Jörg

Avatar

Former Community Member

Hi Jorg,

Here is the paginfo.json request stats

[img]Screen Shot 2015-05-07 at 9.20.08 AM.png[/img]

Avatar

Employee Advisor

Hi,

so it's not a filter, but the PageInfoServlet. Then there might be a number of things, which can cause the observed behaviour:

  • full replication queues (you should observe it then as well when browsing in the siteadmin, as it's getting really slow)
  • you are working a lot with MSM
  • lot of running workflows or workflow models

Can you do a number of threaddumps, when this request is running, and post only the relevant pieces of the stacktrace?

kind regards,
Jörg

Avatar

Former Community Member

Thanks Jorg.

You are spot on. We are doing all the 3 activities as you mentioned. I am trying to take threaddumps from /system/console/status-Threads . Is this correct? or Can you please suggest .

Avatar

Employee Advisor

Hi,

that's one option. The other one is a regular threaddump, see [1] for some recommendations.

kind regards,
Jörg

[1] https://helpx.adobe.com/experience-manager/kb/TakeThreadDump.html

Avatar

Former Community Member

Hi Jorg,

Threaddumps attached. Please rename it to .zip

Avatar

Employee Advisor

Hi,

looks like the time is spent on mongodb... I don't know if there are lots of calls or a very slow single call.

kind regards,
Jörg

Avatar

Former Community Member

Hi Jorg,

Yah I tried with out mongo it seems relatively better. Is it because of the Process time it is taking in Mongo (If this is the case I can try by increasing Mongo specs)? or is it some network issue between mongo and AEM?

Avatar

Correct answer by
Employee Advisor

Hi,

I cannot say, what the problem is, the threaddump does not indicate the number of calls to MongoDB. If course latency is an issue (always). Maybe you can check the number of requests in mongodb.

Jörg

Avatar

Level 4

Hi,

I know this thread is old. I can reproduce the same issue in 6.2 SP1. Did you got a solution for this? For us it is taking 18sec for the page info request.

Thanks

Avatar

Employee Advisor

Hi,

I listed above the 3 potential root causes for a slow pageinfo.json:

  • lots of items in the replication queues
  • lot of MSM activities
  • a lot of workflow packages

To find out more details, do the request and then check the "Recent Request Console" (/system/console/requests) for this request, there are detailled timing information available, which aspects takes how much time.

(This has been added not to long ago; otherwise enable DEBUG logging for "com.day.cq.wcm.core.impl.servlets.PageInfoServlet" and check logs.)

Jörg

Avatar

Level 2

Hi,

Recently we have migrated from CQ5.6.1 to AEM6.2 (SP1+CFP3).

After migration We are also facing the same issue. We are not using MangoDB here. Its normal CRX.

In AEM6.2, I see lot of workflows added (there are 137 workflows in total after migration, and the application specific workflows are very less should not be more than 10). Is this could be the reason? If so, how to avoid this issue?

Because, I am not seeing much information in threaddumps.

Also, the logger is not showing much, except that to get the workflowStatus, it is taking around 5 mins. i.e., to load workflow tab, it is taking time.

Avatar

Employee Advisor

Hi,

if the evaluation of the workflow status is taking long time, it could be caused by this:

* a lot of workflow instances in the systems (the number of workflow models doesn't really matter here).

* a lot of siblings (for which the workflow status is calculated as well, if I recall correctly).

* a lot of workflow packages, which need to checked if the current page is part of it.

pageinfo.json taking 5 minutes is extreme, you cannot work anymore with this system. Can you post the relevant output of the logger? And the relevant parts of the threaddumps?

Jörg