ARS 7.4.3 Slow WebUI Performance

Have you the checked the response times between:

1) Your AR Admin service(s) and the Managed Domains

2) Your AR Admin service(s) and the SQL servers hosting the config DBs

3) The web service IIS host(s) and the Admin service(s) 

I did, I'm getting <1ms to everything which is not surprising.  All the dc's are local to the same data center that hosts the sql db's, the admin service and the web server.

Queries to the admin service, as compared to native ad

420 ms to the admin service (get-qaduser using proxy and service params)

36ms to the dc using get-aduser

leejohnc said:

36ms to the dc using get-aduser

Did you perform this test from your Admin service host(s)?  That's key.  Should be moot though since you mention that all your DC's are co-located in the same data centre as your admin service(s).

I don't worry too much about get-qaduser -proxy being slow because the Quest cmdlets have some built-in inefficiency that goes beyond the connection to AR itself.

i tested from the admin services, and a host that is also on-prem that has access to the web, admin, and sql hosts.  They all produce similar results.  Firefox is smooth, chrome, and edge frequently get the spinning ball of patience rendering search results, and the right hand frame of actions

leejohnc 

Were you able to get some resolution on this? I seem to be having the same issue with navigation in the web portal. Just opening the domain and OU's is slow. Please post anything you may have done to help. Thank you for your time. Lu

We have a BigIP F5 load balancer in front of our webUI servers (prod and dev).  Both env's are exhibiting the same issue.  We notice when we bypass the F5, the speed is much better.

No resolution yet.

ARS seems to render much better in Firefox.  The chromium browsers (edge, chrome) seem to be on the slow side.  I don't know if it's that the version of AngularJS that Quest uses is old, or that ARS evaluates access templates on the server side what you're allowed to see, and then the client browser has to wait on that to render the frames based on that.  

ARS seems to render much better in Firefox.  The chromium browsers (edge, chrome) seem to be on the slow side.  I don't know if it's that the version of AngularJS that Quest uses is old, or that ARS evaluates access templates on the server side what you're allowed to see, and then the client browser has to wait on that to render the frames based on that.  

leejohnc said:

or that ARS evaluates access templates on the server side what you're allowed to see, and then the client browser has to wait on that to render the frames based on that

Yes - this is definitely the case.  At least the first time you navigate to a particular location.  Thereafter, I believe your access is cached for the duration of your session.