# Slow dashboard load time

**URL:** <https://discourse.openondemand.org/t/slow-dashboard-load-time/1616>\
**Category:** Get Help\
**Created:** [August 4, 2021, 7:53pm UTC](https://discourse.openondemand.org/t/slow-dashboard-load-time/1616 "2021-08-04T19:53:42Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![rgas20](https://sea1.discourse-cdn.com/flex015/user_avatar/discourse.openondemand.org/rgas20/32/309_2.png) [@rgas20](https://discourse.openondemand.org/u/rgas20)\
**Post date:** [August 4, 2021, 7:53pm UTC](https://discourse.openondemand.org/t/slow-dashboard-load-time/1616/1 "2021-08-04T19:53:42Z")

</div>

All,

We’ve been having his issue with our OnDemand instance (2.0.10) for a while and haven’t been able to find a solution yet. We’ve tried a few things on our end without luck.

Basically, the dashboard seems to take a very long time to load:

 ![slowlogin](https://us1.discourse-cdn.com/flex015/uploads/osc/original/1X/9d34516eb92893bd7d9ba8b74f96df5276b716ea.png)

The actual authentication part does not seem to be the issue as that happens within a matter of seconds. This was an issue back when we were using LDAP auth and also now with ADFS. It just seems to sit there forever waiting to initialize the dashboard. Common for it to take 30 seconds to a minute or more.

I saw a topic in OnDemand’s [known issues](https://osc.github.io/ood-documentation/latest/issues/overview.html) regarding slow dashboard performance due to ERB logic. The only thing that’s really changed is adding interactive apps such as Jupyter and JupyterLab. To test I backed those up, removed them from the apps directory, restarted OnDemand and the slowness issue is still there.

The only thing that we notice a difference with is that newer accounts tend to take less time to load than established accounts. Meaning if someone is a member of multiple groups in AD, that seems to tack on the amount of time it takes to load the dashboard. Not sure why this occurs though/relevance or what is happening in the background.

Clicking on Job Composer, etc once you’re in yields the same issue:

 ![jobsapp](https://us1.discourse-cdn.com/flex015/uploads/osc/original/1X/8a58be2623a5e6182b850285f8e629fd08925d24.png)

We’ve been stuck on this one for quite some time. Any ideas are really appreciated.

---

<div class="post-metadata">

**Author:** ![jeff.ohrstrom](https://sea1.discourse-cdn.com/flex015/user_avatar/discourse.openondemand.org/jeff.ohrstrom/32/136_2.png) [@jeff.ohrstrom](https://discourse.openondemand.org/u/jeff.ohrstrom)\
**Post date:** [August 11, 2021, 3:32pm UTC](https://discourse.openondemand.org/t/slow-dashboard-load-time/1616/2 "2021-08-11T15:32:22Z")

</div>

I’d turn mod\_auth\_mellon’s loglevel to maybe debug (I _think_ that’s the right module name for Shibboleth ADFS) and it’ll tell you how long it takes the AD to respond.

If ADFS is responding fairly quickly, then it’s the PUN actually starting up that takes a long time. Hopefully ADFS is slow, because that is a much easier issue to solve, or at least triage, because you can see directly in the apache logs that an ADFS request is made at time T and the response 25 seconds later.

If you can’t pinpoint the latency to ADFS, then we’re going to have to look into the PUN startup, which you can execute manually.

Here’s the command to start up a PUN for a user named `jeff`. Now you can `strace` it and/or attach any sort of debugging tools to this command (or even `time` as a spot check).

```auto
[root@ac4df2f20b1e ~]# /opt/ood/nginx_stage/sbin/nginx_stage pun -u jeff

```

Here’s the command to clean up that PUN.

```auto
[root@ac4df2f20b1e ~]# /opt/ood/nginx_stage/sbin/nginx_stage nginx_clean -u jeff

```

---

<div class="post-metadata">

**Author:** ![rgas20](https://sea1.discourse-cdn.com/flex015/user_avatar/discourse.openondemand.org/rgas20/32/309_2.png) [@rgas20](https://discourse.openondemand.org/u/rgas20)\
**Post date:** [August 17, 2021, 2:47pm UTC](https://discourse.openondemand.org/t/slow-dashboard-load-time/1616/3 "2021-08-17T14:47:57Z")

</div>

Jeff, thanks for the reply. It turns out that sssd needed a bit more tuning and after we implemented some changes this seems to have cut down the loading time to about 10 seconds or so. I appreciate the help.

---

<div class="post-metadata">

**Author:** ![jeff.ohrstrom](https://sea1.discourse-cdn.com/flex015/user_avatar/discourse.openondemand.org/jeff.ohrstrom/32/136_2.png) [@jeff.ohrstrom](https://discourse.openondemand.org/u/jeff.ohrstrom)\
**Post date:** [August 17, 2021, 2:50pm UTC](https://discourse.openondemand.org/t/slow-dashboard-load-time/1616/4 "2021-08-17T14:50:01Z")

</div>

Can you specify what the SSSD configs you had to tune? May be helpful for other folks who find this topic.

---

<div class="post-metadata">

**Author:** ![rgas20](https://sea1.discourse-cdn.com/flex015/user_avatar/discourse.openondemand.org/rgas20/32/309_2.png) [@rgas20](https://discourse.openondemand.org/u/rgas20)\
**Post date:** [August 17, 2021, 3:11pm UTC](https://discourse.openondemand.org/t/slow-dashboard-load-time/1616/5 "2021-08-17T15:11:58Z")

</div>

Sure thing,

The main ones that made the most difference were:

ignore\_group\_members = True  
ldap\_purge\_cache\_timeout = 0  
subdomain\_inherit = ignore\_group\_members, ldap\_purge\_cache\_timeout

We also mounted the sssd cache in RAM via fstab.

We have a rather large AD deployment so this seems to have had quite a bit of impact as far as performance goes. I grabbed these suggestions from a Red Hat article [here](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/tuning_performance_in_identity_management/assembly_tuning-sssd-in-idm-servers-and-clients-for-large-idm-ad-trust-deployments_tuning-performance-in-idm).

---

<div class="post-metadata">

**Author:** ![westburg.2](https://avatars.discourse-cdn.com/v4/letter/w/0ea827/32.png) [@westburg.2](https://discourse.openondemand.org/u/westburg.2)\
**Post date:** [May 26, 2022, 3:42pm UTC](https://discourse.openondemand.org/t/slow-dashboard-load-time/1616/6 "2022-05-26T15:42:47Z")

</div>

Closed on May 26, 2022, 3:42pm UTC