Manage Citrix Performance

Instructions to differentiate Citrix-based applications and protect their performance

Dependability, centralized management, and cost savings are some of the reasons people invest in Citrix thin-client/server-based architecture. However, unmanaged network traffic frequently destroys the performance of even the most sophisticated server-based computing environment. Citrix-based applications battle for bandwidth with print traffic, web browsing, large email attachments, and other bandwidth-hungry applications.

Steps:

1. Enable traffic discovery and let PacketWise discover your Citrix-based applications and create a traffic class for each.
   
   For example, if you are running PeopleSoft, Microsoft Exchange, and Internet Explorer over Citrix, your traffic tree might look something like this:
   
   - Citrix
      - Citrix-PeopleSoft
      - Citrix-Exchange
      - Citrix-IExplorer
      - Default
   
   For background information, see Traffic Classification Overview and Traffic Tree Overview.

2. Create additional traffic classes for Citrix applications that have not yet appeared on the network, if you need them.

3. If any of your Citrix applications generate a copious amount of print traffic that undermines interactive performance, then divide a single Citrix published application into two traffic classes — one for print and one for the rest. You can use Citrix tagging as the means to identify an application's print traffic (a tag value of 3 means print).
   
   For example, to isolate PeopleSoft's print traffic, you'd expand your traffic tree to look like this:
   
   - Citrix
      - Citrix-PeopleSoft
          - PSPrint
          - Default
      - Citrix-Exchange
      - Citrix-IExplorer
      - Default
   
   To accomplish this division, select the Citrix application to be the new parent traffic class (Citrix-PeopleSoft, in the example). Then create a new child class, naming it something appropriate with the application name and the word "print." Choose Priority 3 from the matching rule's Citrix-specific classification criteria to identify print. The default class for non-print traffic is created automatically. You can change the name to be more appealing, if you like.

4. Create a partition for the Citrix traffic class to carve off a portion of bandwidth to be available any time Citrix applications need it. The partition size should be at least sufficient to cover the number of users you expect with minimally acceptable performance. Consult Sizing a Static Partition for help in determining the partition's correct minimum and maximum sizes.
   
   Of course, you'll need to balance the performance needs of other, non-Citrix, mission-critical applications and divide resources appropriately. Remember that bandwidth reserved with partitions is never wasted. If unused, it's loaned to other applications in need.
   
   For background information, see Partition Overview.

5. Set rate policies for each child class under Citrix to preserve equitable per-session performance. Use a bandwidth rate that ensures the minimum acceptable per-session performance for the Guaranteed field. Cap the session with a reasonable limit to protect other sessions. Assign a priority that matches the urgency of the application.
   
   For example, the Citrix traffic tree referenced earlier on a T1 link might have the following partition and policy assignments:
   
   - Citrix                    (partition: size 400 Kbps, burstable to entire link)
      - Citrix-PeopleSoft
          - PSPrint          (rate policy: 0 guaranteed, 20 Kbps limit, priority 2)
          - PSDefault      (rate policy: 10 Kbps guaranteed, 30 Kbps limit, priority 6)
      - Citrix-Exchange (rate policy: 20 Kbps guaranteed, 40 Kbps limit, priority 4)
      - Citrix-IExplorer  (rate policy: 5 Kbps guaranteed, 30 Kbps limit, priority 3)
      - Default              (rate policy: 0 Kbps guaranteed, 15 Kbps limit, priority 3)
   
   For background information, see Policy Overview.
   
   You can stop here with a perfectly fine Citrix solution. But if you want additional control, continue with the next steps.
   

6. If needed, you can create additional partitions to subdivide the bandwidth for Citrix among its child classes, the published applications. Usually, this isn't necessary, and rate policies for each child class suffice. One circumstance that might require these hierarchical partitions is when two equally critical, urgent, Citrix-based applications are used concurrently and tend to impact each other.
   
   For example, suppose you have Oracle running over Citrix in addition to PeopleSoft, and you want to give them each the same rate policy. You could create partitions for both Oracle and PeopleSoft giving each, for example, one third the rate you gave to Citrix. (The rest of the Citrix classes would share the other third without requiring further action from you.)

7. It's frequently a good idea to contain applications that tend to consume more than their share of bandwidth in addition to performing the previous steps to protect Citrix traffic. Use the following solutions to help implement this containment goal:

• Identify Performance Saboteurs — spot those troublesome applications that are undermining others' performance.
• Limit an Application's Total Bandwidth — limit the particularly bandwidth-hungry traffic classes to a specific bandwidth cap.