This article provides information on some of the key areas to address to improve stability and performance during periods of high volumes of concurrent logons/session launches.
Note: This article focuses on obtaining the best performance in situations of high concurrent logons. However, in some cases this is achieved by sacrificing other functionality (for example - Session Reliability, more frequent Access Management Console updates, Logon Feedback, and so on) – as such, these recommendations should be tested before applied in full production.

XenApp Architecture

XML Brokers/Data Collectors

During Application Enumeration and Application launch, both of these server roles are under extremely heavy demand and so could pose a bottleneck. The following actions are recommended:

• Multiple dedicated, load balanced, XML Brokers (not Data Collectors, not serving applications).

• Dedicated Zone Data Collectors (Including Backup/Preferred) – not XML Brokers, not hosting applications.

• Do not point Access Management Consoles to Domain Controllers or XML Brokers – possibly even block port 2513 to prevent this occurring.

Web Interface/Farm Aggregation

Web Interface Servers must be dedicated – not an XML Broker, not an application server. Multiple farm environments, where Web Interface is used to aggregate farms – consider that even if applications are not published from all farms to all users who log into the Web Interface, XML Brokers on each farm still enumerate for each user to verify this, on every logon to Web Interface.

Data Store Connection

From Hotfix Rollup Pack 03 for Presentation Server 4.5, Data store connectivity tunes itself automatically.

Static Data Broadcast Batching

Changes to static data (such as farm, server, and application settings) can place a large load on the Zone Data Collectors of a farm. Many common administrative tasks are actually hundreds of updates to the IMA data store.

To reduce the Zone Data Collector load, Hotfix Rollup Pack 03 delays and batches static data updates to combine multiple updates into a single message. Refer to CTX119922 - Improving Farm Performance and Resiliency with Hotfix Rollup Pack 3.

One remaining possible improvement is the Local Host Cache Polling Interval, which can be increased to approximately four hours and might reduce the Data store overhead a little. For more information refer to For XenApp 6.0 – Server 2008 R2: Tuning Local Host Cache Synchronization

XenApp Configuration

Load Evaluators - Load Throttling

This setting determines the load that the Data Collector assumes for a server when it hands over a user logon or session launch to it. This Load value calculated on the Data Collector, avoiding the need for the logon to complete/session to launch before an increased load is reflected on the Data Collector. So the Data Collector is always aware during peak logon times. This assumed/temporary load is stored by the Data Collector until the user logs on or the session launches successfully, at which stage the Application Server (hosting the session) updates it’s new and accurate load to the Data Collector, which then reduces the listed load of that server – placing the “real” load value for that session.

This was implemented to avoid the Black-Hole effect, whereby a server would get all new connections if it were started up during peak logon times because it would be seen as least loaded, and therefore maxed out by all new connections hitting it simultaneously. Or if a server crashed or was rebooted it would also take all new connections (possibly creating a vicious circle in the situation of a crashing server).

If there is a high volume of simultaneous logons, and if the Data Collector is assuming “High” loads for each connection, it very quickly sees the other servers as “Full” before they have a chance to report back their true load values (after the sessions are fully established). Depending on the specifications of the other servers, and the applications involved, they may or may not be actually fully loaded at this point.

Note the algorithm works as mentioned, so on the default setting, given that maximum load is 10,000, it only takes 15 pending sessions (from a starting point of even a minimum load) to result in a server being listed as “Full” on the Data Collector – after which point new client connections to it are refused.

Essentially, the default algorithm is: (New) Current Resolution load = (Old) Current Resolution Load +[(Max Load - Old Current Resolution Load)/2 ]

The values/divisors for the other levels are as follows:
Extreme: 1
High: 2
Medium High: 3
Medium: 4
Low: 5

Consequently, Load Throttling settings must be carefully planned for the environment – to ensure a balance between the Data Collector prematurely assuming fully loaded servers, and re-introducing the “Black Hole” risk described in the preceding section.

Further details on implementing Load Evaluators and Load Throttling, refer to XenApp 6.0 Server 2008 R2: Load Management

Reduce Session Launch Time

Session Reliability

Session Reliability can place an unnecessary overhead on the logon (and the actual session, after launch) – but is not really necessary in a LAN or stable WAN environment – so testing with it disabled might reduce session launch time.

Client Printer Creation

For published applications, try within the Access Management Console or Delivery Services Console, the checkbox on the Client Option property for Printing: Start this application without waiting for printers to be created (Assuming users do not need printers immediately upon logon).

Access Management Console or Delivery Services Console Refresh

Adjust the Refresh Rate of the Access Management Console to a level only as frequent as necessary, see Citrix Documentation Monitoring Session Status.

Logon Feedback

Windows Server 2003 Only: Disable Enhanced Logon feedback for ICA Client – this might remove some of the overhead from the logon process. Try this on an isolated server/test initially.