Sign up for the quarterly Flings Newsletter here!

vSphere HTML5 Web Client

Products:
Communities:
Report a Bug

#268 Dialog boxes are slow to open (~2 min)

Open
  • User
    Chris Duck • about 2 months ago

    Any actions in the UI that generate a "modal dialog" (ie edit settings, create a snapshot) take a long time to open (~2 min). Other actions that to not generate a dialog respond quickly. This happens across Chrome and IE, on multiple computers, for multiple users, and has been a problem on multiple versions of the fling (at least since April?).

    A couple of times immediately after upgrading to a new fling version the problem has gone away, but then it reappeared within a few days. Restarting the services nor rebooting the appliance resolve the issue. Clearing all browser data (cookies, cache, content settings, & hosted app data) does not fix the problem either.

    Chrome's network trace shows a 2 minute wait on time to first byte on the XHR request when I click to generate the dialog box.

    I do not have this problem on the HTML5 client that ships in our VC appliance (version 6.5.0.13000). Our current fling version is 3.40.0.9292689.

  • Dsc 2205
    Abhijith Prabhudev • 8 days ago

    I'm debugging a similar issue from another customer, can you try reregistering the fling via FAMI UI (https://<ip-address-of-the-fling>:5490)? Let us know if reregistation does not solve the problem, in that case, I would ask for more details.

  • User
    Chris Duck • 8 days ago

    You mean re-running the SSO configuration? That's all I see on the FAMI UI...

  • Dsc 2205
    Abhijith Prabhudev • 8 days ago

    Yes, stop the server and re-run the SSO configuration. You can do both from the FAMI UI.

  • User
    Chris Duck • 8 days ago

    Just re-ran the sso config and the dialog boxes are faster. I'll set a reminder for next week to report back in if it's still working. Thanks!

  • User
    Chris Duck • 4 days ago

    Looks like the problem is back. Someone just reported to me that it was still fine earlier this morning and now it is slow again.

    I'm also noticing that chrome is reporting the delay as exactly 2 minutes every time I check it in the network request waterfall.

  • Dsc 2205
    Abhijith Prabhudev • 4 days ago

    A similar issue is reported by another user and we are looking into this. Will update this thread once we find more details. I see that you have provided the VC build information above, is this VC in external PSC configuration or embedded PSC configuration?

  • Dsc 2205
    Abhijith Prabhudev • 3 days ago

    Hi Chris,

    We investigated the issue and found a bug in our fling registration script. We are working on fixing this. Till it is fixed, you can run below workaround to resolve this performance problem.

    1. Get the hostid of the vCenter to which this fling is registered by doing below:
    a) SSH to the vCenter
    b) run this command - cat /etc/vmware/install-defaults/sca.hostid
    c) copy/note down this hostid
    2. SSH to fling appliance
    3. Take a backup of /etc/vmware/vsphere-client/vsphere-client/webclient.properties
    4. Edit the /etc/vmware/vsphere-client/vsphere-client/webclient.properties by updating the vapi.hostid with the hostid noted in 1.c) above
    5. Restart the vsphere-client service in the appliance by running below -
    a) /etc/init.d/vsphere-client stop
    b) /etc/init.d/vsphere-client start

    Note that you should get the hostid from the right vCenter in case you have multiple vCenters configured in the enhanced linked mode using external PSC. To check the right vCenter which is registered with the fling appliance, you can look at the cm.url entry in the /etc/vmware/vsphere-client/vsphere-client/webclient.properties of the fling appliance.

    Could you confirm if these workarounds resolve the performance issues?

  • User
    Chris Duck • 3 days ago

    We have a vCenter appliance with external PSC appliance.

    My webclient.properties file had the vapi.hostid set to the guid of the PSC and I changed it to the guid of the vCenter. After the update the performance issue appears to be fixed. I'll continue to monitor and report back.

  • User
    Chris Duck • 6 minutes ago

    It's been a few days and it's still looking good!

Comment