Problem solve Get help with specific problems with your technologies, process and projects.

Troubleshooting VMware View performance bottlenecks

Performance bottlenecks can tax a VMware View architecture. AppSpeed's monitoring tool can unclog slowdowns -- and alleviate user frustration.

In a VMware View architecture, an overworked VMware View Connection Server (or View Composer database, or vCenter...

server) can create bottlenecks, which in turn can have a devastating impact on the infrastructure and user satisfaction.

But some tools can identify performance bottlenecks, network latency and other infrastructure problems before users take a performance hit. Formerly known as B-Hive, AppSpeed monitors service-level agreements, pinpoints performance bottlenecks and keeps a virtual desktop architecture running smoothly. VMware administrators should consider VMware vCenter AppSpeed as a tool in their arsenal to combat View slowdown and user frustration.

How AppSpeed works

AppSpeed manages front- and back-end components of a VMware View environment, monitoring for bottlenecks from storage performance (which is measured in I/O per second, or IOPS), network latency, log-on "storms" (which I explain below) and more. AppSpeed also monitors end-user requests to the View Connection Server and displays metrics on latency, hit rate and throughput.

The front-end components of a View architecture include the VMware View Connection Server (mandatory) and the VMware View Security Server (optional). The View Security Server is generally used only for end users who access a virtual desktop through a demilitarized zone. The View Composer data base is an example of a back-end component. The front-end components of a View implementation are the gateway through which end users access virtual desktops. If the front-end components experience high latency, slow response times, packet loss or other difficulties, end users will struggle to quickly and efficiently access their virtual desktops.

When many users attempt to log on to virtual desktops in a relatively short period of time, a log-on storm can occur. If the total VDI user base is 500 users, and 300 of them attempt to log in between 8:00 a.m. and 9:00 a.m., for example, the group action can have ripple effects on the View Connection Server, the View Security Server, the View Composer database, vCenter, the vCenter database and the underlying network and storage infrastructure.

Using VMware AppSpeed with VMware View

This article assumes that you already have AppSpeed installed and configured, so it should immediately detect the View Connection servers.

It is recommended that you use your own Secure Sockets Layer (SSL) certificate for the VMware View Connection Server (and Security Server). (If you're not familiar with how to do so, the VMware View Administration Guide offers detailed instructions.)

For this example, we'll use an environment that has one View Connection server.

  1. From the AppSpeed tab (located in vCenter), go to SSL Management. This allows you to add the SSL certificate so that AppSpeed can properly monitor the encrypted traffic of the View environment.
  2. You should now see your View Connection servers, in this case,, listening on 443 (SSL).
  3. Click Add/Update SSL Key. [image]
  4. Once the certificate has been installed, AppSpeed should immediately recognize traffic (assuming the environment is in use).

We now have several graphs and charts available at our disposal, including the following:

Latency. This graph shows the average, maximum latency in milliseconds (think like a European :change the commas to decimal points).

The example View connection server is at about 2.9 milliseconds (ms) average (2.6 ms standard deviation), and most important: There is a 13.9 ms maximum.

Latency is commonly the first metric View administrators inspect; a high-latency metric could indicate insufficient resources for the incoming user load.

Click to enlarge.

Latency breakdown. This graph shows whether the latency stems from an application, the infrastructure in general, or from the network. In this instance, application indicates the time from when the server starts receiving request to when it starts its reply; infrastructure indicates the time from when the server starts sending the reply to when the reply is fully complete, and network indicates the, response time from the client request to the server reply; or network overhead, which is the cost of retransmissions, packet loss and errors.

In a local area network-based VMware View scenario, we would expect the majority of latency to be attributed to overall application response time. In a wireless area network (WAN)-based VMware View scenario, however, the WAN link augments overall latency experienced by end users.

Remember that AppSpeed measures client requests to the View connection server, not Remote Desktop Protocol/PC-over-IP session latency.

Click to enlarge.

View Composer database latency. The Composer is another component of VMware View that AppSpeed can monitor. The level of granularity is impressive and drills down to the performance metrics of specific queries. This metric indicates whether the Composer database has slowed the provisioning activities necessary to maintain a happy and healthy virtual desktop infrastructure pool.

Click to enlarge.

Taking action on performance issues 

The View Composer database sees load during the building of new linked clones and during other linked clone-related tasks, such as recomposing or rebalancing. By monitoring the database, an administrator can identify tasks that have a profoundly negative impact on the View environment and that should be rescheduled for less busy time.

AppSpeed can also highlight an overall performance issue with the underlying server hosting the View Composer database.

AppSpeed can monitor several areas of a View environment to identify performance bottlenecks and address a poor VMware View user experience. Using AppSpeed's feedback to make necessary hardware upgrades, database maintenance scheduling changes or allocate additional resources to support bottlenecks caused by log-on storms can help make a VMware View implementation more successful.

ABOUT THE AUTHOR: Jason Langone heads virtualization, cloud computing and storage for MicroTech, a service-disabled, veteran-owned and 8(a) small business. He has spoken at VMworld, Green Computing Summit and Virtualization Congress. Langone won the VMware Vanguard Award in 2007 and has architected some of the largest virtualization and cloud computing implementations to date. His solutions have been primarily implemented at Fortune Global 500 and public sector organizations and have received various accolades. Langone's focus remains on designing virtualization and cloud computing solutions in large-scale environments.

Dig Deeper on VMware how-tos

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.