Citrix XenApp Performance Essentials: A practical guide for tuning and optimizing the performance of XenApp farms using real-world examples

The data store is the repository for all the static information of your farm (farm, servers and applications configurations, administrative accounts, and so on).

Each session-host server in your farm needs a constant connection to the data store. When the Independent Management Architecture (IMA) service starts, it queries the data store and stores the farm configuration in the local host cache (LHC). Every 30 minutes, the IMA service then contacts the data store to ensure that its LHC is consistent.

If you deploy your session-host servers specifying the session-only mode, you may reduce the data store load and make the startup and join processes faster, as they require less data during the join and sync process.

During the setup wizard, you are asked to choose a database. You can choose New database to install a local instance of SQL Server Express or Existing Microsoft SQL Server database to use a database server already present on your network.

The free SQL Server Express is suitable for small (< 100 servers) farms, while for bigger farms I strongly suggest the use of an enterprise-level database server, possibly in a high availability configuration (such as Microsoft Cluster, Oracle RAC). If the data store is unavailable you can't make changes to the configuration of your farm; moreover if servers reboot, the IMA service won't start and they will no longer publish applications.

In both the cases you should not install other components on the servers that run your database.

XenApp does not usually require much storage for the database. A typical storage requirement is as follows:

The data collector manages all the dynamic information of your farm (active and disconnected sessions, server loads, and so on). It also performs resolutions, that is, when a user requires an application, the data collector finds the least loaded server that can run that application.

It is, therefore, a key component in the application startup process. A slowness in the resolution process increases the overall time a user has to wait before the requested application is launched.

You need one data collector for each zone in your farm. A zone is a configurable grouping of XenApp servers; a farm requires at least one zone and all your servers must belong to a zone.

The main purpose to configure zones is to create a hierarchical structure to efficiently distribute changes:

Zones are useful in a geographically distributed topology; for example, when your company has more than one site connected with WAN links. Zones are not necessary to divide servers in the same site. I worked with XenApp farms with more than 500 servers in one zone.

Citrix recommends keeping the number of zones in your farm to a minimum with one being optimal. Every time a dynamic event occurs, indeed the data collector of that zone must forward the event to the data collectors of the other zones: this replication consumes CPU and bandwidth.

The following figure is a flowchart by Citrix that helps to decide how many zones you need to deploy:

How to choose the farm topology

Data collector stores the entire event in the RAM memory. Its consumption depends on the farm size (number of servers, applications, and so on) and usage (number of active sessions and so on). However, this is usually not significant; for example, a data collector in a large farm (about 500 servers) I administer, uses an average of 250 MB of memory. Similarly, CPU usage is not significant. It may increase only if you create several zones in your farm but this is a discouraged practice. Anyhow, I strongly suggest you to dedicate one server to act as the zone data collector; if the data collector is running on a server that also publishes applications, it may experience resource contention and the resolution process may slow down.

Farms choose the data collector for each zone with an election between all the servers in the zone that can run the component (session-host only servers are excluded). XenApp administrators may change the election preference for each server to statically choose which server will be the data collector for the zone. The following screenshot displays the election preference options for the data collector:

Changing the election preference

Set the election preference to Most Preferred only on the dedicated server to be sure it will be chosen as the data collector during the election process.

If the data collector becomes unavailable, a new election is performed. You may also consider to define the backup server (a second dedicated server or a server running rarely used applications) setting its election preference to Preferred. The other servers in the farm should keep the default value (Default Preference).

The XML Broker is a component used by the Web Interface to retrieve information about the published applications. When a user logs on to the Web Interface, it displays the list of applications retrieved from the XML service to the user. When the user selects an application, the XML Broker responds with the address of a server running that application.

As the XML Broker works closely with the data collector, it is recommended that you install the XML Broker on the same server running the data collector component. If you add more XML Broker servers, you can configure the Web Interface or add an external load balancer (for example, a Citrix NetScaler) to balance the requests between them. The following screenshot displays the option of selecting an XML Broker server for load balancing:

Load balancing XML Broker servers

The license server stores and manages Citrix licenses. The first time a user connects to a XenApp server, the server checks out a license for the user. Subsequent connections of the same user share the same license.

A single license server is enough for farms with thousands of servers and users; you could install a second license server in your farm but the two servers cannot share licenses. Because the license server is contacted when the user connects to a XenApp server, slow responses may increase the login time. You should place the license service on a dedicated server or, in case of small farms, on a server that doesn't publish applications. The license server process is single-threaded so multiple processors do not increase its performance.

If the license server is not available, all the servers in your farm enter a grace period of 720 hours; during this period users are still allowed to connect. This means that you usually don't need a high-availability solution for your license server. If a server fault occurs, you can install a new license server during the 30 days of the grace period or power on a second license server you prepared and kept turned off (cold standby).

The Web Interface provides users access to the published application through a web browser. It's an application running on IIS 7 Web Server and developed in Java/.NET.

A single Web Interface, running on a Dual Core Xeon Server, can handle up to 7 to 8 requests per second. You should expect many connections to the Web Interface when the users arrive at work in the morning or after lunch, so size your Web Interface server based on the number of users you expect will log on at the same time.

A tip to provide high availability and load balancing for this component is to deploy two Web Interface servers and balance the incoming connections using an external HTTP load balancer, as shown in the following diagram:

Citrix Web Interface with external balancer

Citrix XenApp supports five ways to deliver applications to the users. Each method has pros and cons and the choice of one or another highly changes the resource requirements of the session host servers. The methods are explained in the following sections:

The traditional and most common method to deliver applications is to install them on the session host servers. Two strategies available for placing applications on servers are: siloed and nonsiloed.

Provisioning Services sites allow administrators to logically group items that belong to the same physical site (for example, all the resources located in the headquarters or in a branch office). You need at least one site, which is created when you install your first Provisioning Server. Administrators may create different sites to delegate administrative tasks. You can indeed create accounts that can only administer items in a given site.

A site contains some elements, the most important of them are:

A target device belongs to one device collection. Views provide an alternative method for grouping and managing target devices; a target device may indeed belong to different views. You can create views at farm level or at site level; a view at site level may only contain devices from the same site, while views at farm level may contain all the target devices in that farm.

You can perform some administrative tasks at view level, so views become useful with a large number of target devices. For example, you can reboot all the session host servers that publish an application adding them to a view and issuing the Restart... command at the view folder.

A store is a storage location where you save your vDisks. It may be a local hard disk or a network share.

vDisks are disk image files. They consist of a .vhd file (contains the data of the virtual disk), any properties files (.pvp, contain disk geometry, and configuration), and, if applicable, a chain of differencing disks (.avhd).

vDisks may be configured in the following two modes:

In shared image mode, target devices can only read the content of the vDisk. Write requests can be cached in four different ways as follows:

Cache on a server persistent

All the previous options are volatile; write cache is lost when the target device reboots. With the cache on a server persistent option, you can set the cache file to be persistent: Provisioning Server creates a cache file for each target device and doesn't clean it if the target reboots. A drawback is that any changes to the original vDisk invalidate all the cache files.

Note

Invalid cache files are not automatically deleted. Remember to periodically check if any exist and manually delete them to free some space.

The following screenshot displays the different ways of caching write requests to disks:

vDisk modes

No disconnected sessions must remain when virtual users disconnect from servers. Select ICA-TCP connection and select End session as shown in the following screenshot:

Ending sessions automatically

Before being able to run any tests, you need to configure your license server. When a test is performed, the Controller checks for a valid XenApp Enterprise or Platinum license. If a license is found, you can run as many users as required.

Open the Controller, in the toolbar you can find a button to open the Licensing Server Configuration dialog, enter the address and the port number of your license server and click on OK.

In your script, you need to define how users will connect to your XenApp infrastructure.

Right-click on the Connections node and select Add connection...; enter the name of the Launcher server from which connections will begin.

If you want to connect to a published desktop, select Server and enter the server name in the Connect To field.

If you prefer to launch an application through the Citrix Web Interface, select Web Interface and click on the Browse... button.

Insert the address of the server that hosts the Web Interface. You usually don't need to change the port number (80 is the default) or Login and Application Page addresses (you selected those addresses when you installed the Web Interface Support component). Enter the account details of a user that could connect and click on Search.

In the Applications tab, you should see all the applications published for that user, select the application your script will test and click on Select.

Creating a connection to the Web Interface

For each connection you created, you have to define virtual users. Virtual users are used by Launchers to perform the test. You have to create the users, (usually in your Active Directory) and enable them to connect to your farm, and launch the application(s) you want to test.

If you named your test users like:

with the same password, the Add Users to Connection dialog helps you to add them at one time. Enter the number of the users to be added in the Count field, then type the base username in the Username field and tick the # checkbox.

Complete the Password and Domain fields and click on OK, EdgeSight will add all the users for you as shown in the following screenshot:

Adding new virtual users

The load defines how long a test will last, how many users will execute it, and at what rate users connect to the server.

If you select the Concurrency checkbox, the system attempts to maintain a given number of virtual users during the test, ramping their count between the start and end values.

If you select the Rate checkbox, the system attempts to create new virtual users at the rate specified.

The easiest way to define the actions virtual users will perform is to record them during an interactive session.

You may select the user that will connect to the server by left-clicking on the user's icon or let the system choose the first user for you.

Select the Instructions folder and click on the Record Test button. The recording session begins and EdgeSight records all the commands you enter. The session ends when you close the connection or if you click on Stop/Cancel Test button in the main toolbar. If you stop a recording, you can restart it by clicking on the Continue button, while if you cancel it, no instructions are saved.

At the end of the recording, instructions are listed in the Instructions folder.

You can change the recorded instructions or add new ones. Instructions are keyboard/mouse commands or even complex Jscript scripts. You can also group instructions in folders and add breakpoints for debugging.

When your test plan is ready, you can run it using the Replay test button in the main toolbar.

During the test execution, you may watch the virtual users' actions and if you click on the Display node, you can get real-time statistics, as shown in the following screenshot:

Real-time statistics