When you have set up your vSphere services and your sys-admins start to use the web client to manage their vm’s, you might get reports back that the web client is slow compared to the old legacy client.  This might happen after some time, depending on the size of your setup, but at some point you might have to scale out the inizial vSphere installation. After you google the subject on slow web client experience you’ll find out that this is pretty common topic. But what can you do about this?

Here I have listed up several solutions that have helped me to provide a better experience for the sys-admins that manage their vm’s. The list is not ordered by “success rate” and your environment might benefit more from different points in the list. This also is an overkill if you have a small deployment. – But hopefully this can help you providing better user experience for the web client.

1. Separate the services. Split it down to  4 separate vm’s: SSO and integration service vm. vCenter server vm,  web client service vm and finally update manager vm. This will help you better serve the different types of services and split down the installation to 4 failure zones. This separation will also make life more easy when you upgrade to newer versions of vSphere. Plus those 4 vm’s, you have the database service vm, vMA appliance, replication appliance etc..
2. Assign right amount of vCPU’s to the vm’s depending on their roles.

• SSO and integration service vm has 2 primary java processes, but as user performance is not so bound to this vm performance, 1 vCPU should be just fine. If your installation is distributed and you have multiple vCenter installation, you might want to look at this vm better, and separate the integration service from this vm, and have it run on the vCenter service vm.
• Web client service run one primary java process, and 2 vCPU’s is good for this machine and it’s performance is vital for your sys-admins.
• vCenter service vm has 2 primary java process running, and 4vCPU vm should be able to serve those processes well.
• Update manager vm can have 1 vCPU, as it’s workload is not affecting your web client users.

3. Assign more memory to the java processes than default settings are, and based on my experience, much higher than the guidelines you find on this subject from VMware… I had huge improvements when I did this.  First assign  6GB  RAM to the web client vm, and 24GB to the vCenter vm. Then adjust the java memory settings.
   There are 2 settings to take note of, initial size and max size. Set both values to the same amount. For the web client web service, set it to 2GB, in file; “C:\Program Files\VMware\Infrastructure\vSphereWebClient\server\bin\service\conf\wrapper.conf”
   wrapper.java.initmemory=2048m
   wrapper.java.maxmemory=2048m

and on the vCenter service vm set the 2 main java processes service
“C:\Program Files\VMware\Infrastructure\tomcat\conf\wrapper.conf”
Under “Java Additional Parameters”
wrapper.java.additional.9=”-Xmx16024M”
wrapper.java.additional.10=”-Xss16024K”

And  it might be beneficial for your to also change this in file “C:\Program Files\VMware\Infrastructure\Profile-Driven Storage\conf\wrapper.conf” –

# Initial Java Heap Size (in MB)
wrapper.java.initmemory=1024

# Maximum Java Heap Size (in MB)
wrapper.java.maxmemory=1024

4. Run the vCenter service vm and the database server vm on the same host, and the other main 3 vm’s on a different host. The database vm and the vCenter service vm have a lot to talk about so to speak, so placing them on the same host helps in regard of both network traffic and latency concerns.
5. Publish the web client service to your admins via an Citrix Netscaler appliance You get a lot of benefits from this. Just remember to publish both port 9443 for the web service, and port 7331 (or 7343 if you have vSphere 5.5 Update 2) for console access.
   To name a few of the benefits of using Netscaler in front of the web client service vm:

• SSL off-loading from the web service vm. Even if you use the default SSL port 9443 to the web client service, you terminate and multiplex the TCP sessions on the Netscaler and therefore you get only few sessions to the web service. SSL load on the web service vm is moved to the SSL chips on the Netscaler so you have less CPU load on the vm.
• Use http to https redirection . you can tell your sys-admins to browse directly to the DNS name you set. Like for example http://vsphere.company.local and the don’t have to worry about having to remember port 9443, or type https, as you set up the redirection and port translation on the Netscaler virtual server and service.
• Use in memory cache in Netscaler to offload from the web service vm.
• Use acl’s to control what subnets or ip’s can access the web client service.

I hope this guide can help your vSphere Web Client to run faster, – and bear in mind, the settings on Java memory sized might not be the best options for your setup, but this is what I have done to tune my installation to run more smoothly.

 

I use Veeam for backups of my environment, and it generates a quite amount of load on the vCenter server vm, so give it plenty of resources .