Troubleshooting performance issues of any application is a challenging exercise because there are usually so many factors to consider, and this is just as true with Embotics® vCommander™ as any other. This article describes the steps you can take on your own to troubleshoot performance problems, and how to help our support team if you’re unable to determine a root cause.
There are three audits that you will perform to assess performance issues, looking at users, environment, and the application itself.
The first thing to determine is whether or not the issue is isolated to the user account with which you are logged in. It’s possible under some circumstances this will be relevant. The easiest way to test this is to create another user account and see if you get the same results.
Also, it’s important to try operating vCommander from more than one computer, to make sure that there aren’t issues with the client computer from which you are connecting. Malware infections or security software against them can sometimes degrade access speed and make it appear that the application is performing sub-optimally when the problem is entirely with the client computer.
Having confirmed that the problem is not isolated to one user or client computer, determine whether or not the application has been given the resources it needs to perform properly. Remember that an initial installation that worked very well with the minimum requirements will not necessarily continue to run well once you’ve added more managed systems and their VMs.
Similarly, a shared database configuration (where the vCommander database is hosted on the same SQL Server as other applications’ databases) may eventually yield reduced performance as vCommander, or the other applications, become more active and contend for resources.
Always check the performance of the application and database servers when troubleshooting performance issues, and if the systems are virtualized, check the performance metrics provided by the managed system as well, such as the performance data exposed for each VM by VMware.
Once you are satisfied that the performance is not being impacted by the environmental factors, the next thing to consider is whether the performance issues are present in all areas of the application or isolated to when certain activities are being performed.
For example, it’s possible to experience slow logins when using Active Directory accounts, but the performance of once logged in is normal. When this is the case, there are solutions available to speed up login times or tweak how the integration with your directory works.
It’s also possible that an issue exists with one or more records for VMs hosted in one part of your infrastructure which will not affect the performance when working with other objects. For example, there may be issues with a VM in one host that slows the system down when parsing records for only that host, so listgrids or reports on VMs deployed there will be slower than the same activity for other hosts.
The best way to help the support team assist you once you’re certain that the application performance has degraded, is to note exactly what you were doing, and at what time. If possible, use a tool like Jing to capture a video of the performance issue or contact support to do a webex where the issue can be observed live.
Once support has seen the issue, they will request you submit the diagnostics to review what was logged in the background during the time of the observed performance problem. Additional debug logging being turned on may also be requested.