Log In to Comment

• 
  Chris Duck • Aug 09, 2018

  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.

• 
  Abhijith Prabhudev • Aug 09, 2018

  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.

• 
  Chris Duck • Aug 09, 2018

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

• 
  Abhijith Prabhudev • Aug 09, 2018

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

• 
  Chris Duck • Aug 09, 2018

  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!

• 
  Chris Duck • Aug 13, 2018

  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.

• 
  Abhijith Prabhudev • Aug 13, 2018

  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?

• 
  Abhijith Prabhudev • Aug 14, 2018

  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?

• 
  Chris Duck • Aug 14, 2018

  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.

• 
  Chris Duck • Aug 17, 2018

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