Slow "index.action"
Asked by Florian:

I am evaluating the latest greatest confluence version.

When I access my instance it is blazing fast (I get the start page of confluence in about a second). But when I don't access confluence for a few hours, it takes up to 10 seconds to load the start page.

I turned on the profiling and looked at the log. It looks like most of the time is spent on this action:

\[4595ms\] - XW Interceptor: Before defaultStack: /index.action (IndexAction.execute())

There are no sub-steps that would help to narrow down the problem.

I'm evaluating confluence in a docker container on an 8-core C2750 Atom-processor with 16GB RAM. Clearly, the processor is a limiting factor. But maybe there is a way to optimize confluence?

Does anyone have an idea? Is this CPU, RAM or IO related?


Answers:
author: AnnWorley
body: I understand you are evaluating Confluence 6.8.1 on a Docker instance. When you leave the instance idle for a few hours it takes a long time to load the landing page. Are you using the default landing page?

The only idea I have off the top of my head is that it probably isn't a load issue since you are the only user. That it is faster after you use it a few minutes indicates caching as a factor but it could be browser, OS or database caching.

There are a lot of suggestions on this page in case you have not seen it, could be a good place to start: [Performance Tuning](https://confluence.atlassian.com/doc/performance-tuning-130289.html).

I look forward to hearing what you find.

comments: author: Florian
body: Thank you for your reply.

I think it's really a CPU issue. The C2750 (Atom based CPU) is really not performing well on confluence. I had a VPS on <http://scaleway.com/> and also a local machine (with a C2750) and both performed equally bad. The 8 cpus are at 95-100% during the mentioned 10 second time window.

Now, on another VPS provider, I rented a VPS with 2x Intel Skylake and I don't have to wait 10 seconds anymore. It had reduced to 4-5 seconds, which I think is acceptable.

But honestly, I don't understand what confluence is doing during that time.

I am the only user on the instance, nobody else is using / evaluating it. Is there no possibility to just keep the cache for a longer period?


author: AnnWorley
body: I was only guessing about the caching based on your original post, but to help isolate the issue, please have a look at your cache statistics as described in [Cache Performance Tuning](https://confluence.atlassian.com/doc/cache-performance-tuning-169119133.html).

Please also check the database server logs to see if there are any errors or slowness when accessing the database.

Another place to look for slow tasks is in the browser's developer console, especially the Network tab. For example, in Chrome's developer tools, Network tab, Size column shows whether the data is being loaded from memory cache, disk cache or the size of the file if it's pulled from the server:![Screen Shot 2018-04-23 at 3.08.09 PM.png](https://community.atlassian.com/t5/image/serverpage/image-id/20421iDC22CE0E5D75F030/image-size/large?v=v2&px=999 "Screen Shot 2018-04-23 at 3.08.09 PM.png")


author: Florian
body: Yes, I have done that already. I checked both the Cache Performance Tuning page and the Performance Tuning page as well as the logs. The reason I'm posting here is exactely because the official guides do not cover that case.

According to these guides, the cache usage and effectiveness isn't really the problem (Not even speaking of the fact that an empty (!) instance shouldn't need to be "cache tuned", but that's a different story)..

I also already looked at the network tab and about 90% of the mentioned 10 second time window the browser is waiting for the first byte (ttfb).

Also, I tried both the integrated database and a Postgres database on a dedicated machine and both instances performed equally bad.

It is sad that an empty (!) instance of confluence consumes so much CPU power. The fact that I have to struggle with performance issues on an empty (!) installation already doesn't want me to continue anymore with confluence. I cannot afford to buy a higher VPS after adding a few pages...


author: AnnWorley
body: Hi Florian,

I run a number of test instances and have never see the behavior you are describing so I tend to think it isn't Confluence itself, but rather "something" about your infrastructure. It's hard to diagnose on the forum because there are so many unknown variables.

If you are meeting the [minimum hardware requirements](https://confluence.atlassian.com/doc/server-hardware-requirements-guide-30736403.html) and still seeing the unexpected CPU usage, please consider paying for the services of an Atlassian Solution Partner. You may find one in your area by using this [search page](https://www.atlassian.com/partners/search?page=1).

Thanks,

Ann


author: Dan Taube
body: Not looking to resurrect a seemingly dead (quiet for a few months) post, but we are seeing the same with more than minimum hardware requirements. We experience it within the first attempt to access a page after no one has been on it for a couple hours.

It seems like a service is being woken up after idling for some time rather than just a caching issue.

Version 6.10.1

Here's the primary results from profiling on first access attempt showing the items that take up the most time (i.e. slow load):

```
2018-08-27 12:33:01,077 DEBUG [http-nio-8090-exec-393] [atlassian.util.profiling.UtilTimerStack] log [35368ms] - /
[30904ms] - XW Interceptor: Before defaultStack: /index.action (IndexAction.execute())
 [14443ms] - PageAwareInterceptor.intercept()
  [14441ms] - XW Interceptor: After defaultStack: /index.action (IndexAction.execute())
   [14408ms] - XW Interceptor: Before defaultStack: /pages/viewpage.action (ViewPageAction28.execute())
    [14407ms] - PageAwareInterceptor.intercept()
     [14345ms] - XW Interceptor: After defaultStack: /pages/viewpage.action (ViewPageAction28.execute())
      [14345ms] - XW Interceptor: After validatingStack: /pages/viewpage.action (ViewPageAction28.execute())
       [14058ms] - XW View: doExecute(/pages/viewpage.vm)
        [14055ms] - ApplyDecoratorDirective.render()
         [14047ms] - Rendering velocity template: /decorators/root.vmd
          [14047ms] - ApplyDecoratorDirective.render()
           [14044ms] - Rendering velocity template: /decorators/page.vmd
```

Here's the results after this attempt when everything comes up quickly right after the first slow attempt (i.e. quick load):

```
2018-08-27 12:33:29,631 DEBUG [http-nio-8090-exec-387] [atlassian.util.profiling.UtilTimerStack] log [168ms] - /
[95ms] - XW Interceptor: Before defaultStack: /index.action (IndexAction.execute())
 [94ms] - PageAwareInterceptor.intercept()
  [93ms] - XW Interceptor: After defaultStack: /index.action (IndexAction.execute())
   [82ms] - XW Interceptor: Before defaultStack: /pages/viewpage.action (ViewPageAction28.execute())
    [82ms] - PageAwareInterceptor.intercept()
     [76ms] - XW Interceptor: After defaultStack: /pages/viewpage.action (ViewPageAction28.execute())
      [76ms] - XW Interceptor: After validatingStack: /pages/viewpage.action (ViewPageAction28.execute())
       [50ms] - XW View: doExecute(/pages/viewpage.vm)
        [50ms] - ApplyDecoratorDirective.render()
         [48ms] - Rendering velocity template: /decorators/root.vmd
          [48ms] - ApplyDecoratorDirective.render()
           [47ms] - Rendering velocity template: /decorators/page.vmd
```


author: David Thielheim
body: Was there a solution regarding this issue? Have exactly the same and no idea how to fix it. Like mentioned above, i also would like to know the service or process keeping "not going to sleep", when comming back to a confluence page after a while...


author: Florian
body: I have the impression that there is no solution from a software point of view. I guess for Atlassian there is no problem either, because most customers have enough CPU, RAM and IO. This problem is just not severe enough for them to change anything.

For startup companies, its hard to meet a hardware level good enough to actually use this solution. Yes, the minimum hardware requirements exist, yes the solution works with the minimum specs, it just... well... works really bad with them.

Atlassian should massively increase the minimum hardware requirements.

Good luck mate...