Citrix states in their article: CTX020367

CTX020367 - How to Analyze the Citrix Server Test Kit Results

This document was published at: http://support.citrix.com/kb/entry.jspa?externalID=CTX020367

Document ID: CTX020367, Created on: Jul 24, 2000, Updated: Apr 23, 2003

Products: Citrix MetaFrame 1.8 for Microsoft NT 4.0 Server Terminal Server Edition, Citrix MetaFrame 1.8 for Microsoft Windows 2000, Citrix WinFrame 1.8

The Citrix Server Test Kit (CSTK) is an automated tool that can be used by administrators of Citrix servers to configure and run various user load configurations. It can be used to demonstrate ICA connectivity or provide consistent, repeatable user loads that test various hardware configurations.

The CSTK allows the Citrix administrator to simulate various user loads by using application simulation scripts. The scripts simulate various uses of typical software applications and run without any user interaction. The advantages of the CSTK include:

• Multiple sessions can be connected from a single client machine.

• Once the client sessions are connected, the entire test can be administered from the server console.

• The CSTK allows the same tests to be run time and again in a deterministic manner, without the need for human testers.

This provides consistent results with reproducible performance data.

The CSTK can provide some basic data points for scalability analysis. When analyzing test results, consider the following factors:

• An instance of the CSTK Client is running for each client session. This introduces additional load on the server that you must take into account.

• The scripts do not exercise many ICA virtual channels such as client-side sound, client printer mapping, client com port mapping, and so on.

Performance Monitoring

Detecting the source of a performance problem is not always a straightforward task. It requires running several tools over several iterations, examining computer performance, and repeating the tests in a rigorous, scientific manner.

A bottleneck is a condition in which the limitations in one component reduce the operating speed of the entire system. The device with the lowest maximum throughput is most likely to become a bottleneck if it is in high demand. Making any other device faster cannot yield more throughput - it results only in lower utilization of the faster device. The best bottleneck alarm is the system response time as perceived by the users. Their perceptions are influenced by the kind of work they do and their expectations of application response time.

Although 100% utilization of a resource is a clear warning, it is neither a necessary nor sufficient reason for a bottleneck. Bottlenecks occur on devices with utilization well below 100% and a device running at nearly 100% utilization may display no signs that it is a bottleneck.

Recording System Configuration

For each iteration of a test, record these parameters:

• Processor type and speed

• Number of Processors

• Memory

• Hard drives

• Network interface

Processor Type and Speed
CPU type and speed need to be recorded for every test. Several parameters can be recorded in order to measure the CPU.

Record these parameters with Performance Monitor during the test:

• %Total Processor Time (System object) - The average percentage of time that all the processors on the system are busy executing non-idle threads.

• Processor Queue Length - The instantaneous length of the processor queue in units of threads.

Recognizing Bottlenecks
CPU bottlenecks are fairly easy to recognize. A high average of % total processor time with an average processor queue length greater than two signifies that CPU is congested.

How to Relieve the Bottleneck
CPU shortage can be fixed in two ways:

• Replace the existing CPU with a higher speed CPU.

• Add more CPUs to your system. Replace a single processor with a dual processor or a dual processor with a quad processor system.

Memory
Memory is one of the easiest components to increase in size. Record the following parameters with Performance Monitor during the test to measure memory bottlenecks.

• Page Reads/sec - The number of pages read from the disk to resolve references to pages that were not in memory at the time of the reference. Also known as hard page faults.

• Page File Size used: The size of the paging files on disk. The current value can be found in the System option of the Control Panel.

• Free System PTEs - Number of page table entries not being used by the system.

Recognizing Bottlenecks
The best indicator of memory bottleneck is a high page fault rate. Expect relatively high page fault rates when applications initialize. Although high soft page fault rates warrant attention, it is the hard page faults that slow the system considerably and degrade performance. Sustained hard page fault rates over five per second are a clear indicator of memory scarcity in a system.

To measure hard page faults, monitor Page Reads/sec (the frequency of the system reading from disk because of page faults). Another indicator of memory shortage is Logical Disk: %Disk Time. As paging increases in a system, code or data pages are written back to disk (Pagefile.sys) to free up page frames. New pages retrieved from disk use these free page frames. Therefore as paging increases, disk activity increases proportionately. Sustained disk activity of over 40% is a cause for concern.

How to Relieve the Bottleneck
There is only one way to relieve memory bottlenecks - add more memory.

Hard Disk
Hard disks are the slowest part of a system. Record the following parameters with Performance Monitor during the test to measure hard disk performance.

Record these parameters with Performance Monitor during the test:

• % Disk Time (Physical Disk) - The percentage of elapsed time that the selected disk drive is busy servicing read or write requests.

• Pages/sec (Memory).

Recognizing Bottlenecks
Determining if the bottleneck is the disk or memory can sometimes be difficult. When memory starts running out, there is increased disk activity because memory is reading heavily from virtual memory. When this happens, memory is the bottleneck, not the hard disk. The disk is the bottleneck when the % disk time average is over 40% and hard page faults are low (under 5/sec).

How to Relieve Bottleneck
To relieve hard disk bottlenecks, get a faster hard disk or spread the files over several disks. There are many ways to improve hard disk performance. If the disk drive uses an IDE interface, upgrade to SCSI; if it is a 7200 RPM drive, upgrade to a 10000 RPM drive, and so on.

Network Interface
In order to record network performance, install
the Network Agent Monitor as a network service.

Record this parameter with Performance Monitor during the test:

• Bytes Total / sec (Network Interface) - The rate that bytes are sent and received on the interface, including framing characters.

Recognizing Bottlenecks
The network interface bottlenecks when the Bytes Total/second approaches the speed of the network card. A 10Mbps card bottlenecks
at about 1 megabyte per second (Mbps). This is very dependent on your network.

How to Relieve the Bottleneck
If the network is slowing down the overall performance, there are some quick ways to relieve some network traffic. One way of relieving traffic is to remove protocols that are not being used. For example, NetBIOS can cause more traffic than TCP/IP or IPX.

Other Recording Parameters

Other parameters that help measure overall system performance are:

• Script execution time

• Objects: Processes - The number of processes in the computer at the time of data collection

• Objects: Threads - The number of threads in the computer at the time of data collection