CitrixXenApp 6 Scripting With Loadrunner Best Practices v2.31 PDF
CitrixXenApp 6 Scripting With Loadrunner Best Practices v2.31 PDF
VERSION 2.31
DOCUMENT
References
Client Titre Suject Version
Realisation
Write by Check by Approve by
Revision
Version Object Date
File
Reference Name
1. Introduction ..................................................................................................... 4
2. Fundamentals .................................................................................................. 4
2.1 About Citrix/XenApp technology ........................................................................... 4
2.2 About HP LoadRunner – Performance Center ........................................................ 5
3. Getting started ................................................................................................. 5
3.1 Requirements for LoadRunner – Performance Center ........................................... 5
3.2 How many load generators will I need? ................................................................ 6
3.3 Citrix Clients ........................................................................................................... 6
3.4 Server Side Considerations .................................................................................... 8
4. Creating “Citrix_ICA” scripts with LoadRunner – Performance Center ........... 9
4.1 Recording ............................................................................................................... 9
4.2 Recording tips ...................................................................................................... 11
4.3.................................................................................................................................... 13
4.4 Understanding some of the code.......................................................................... 14
4.4.1 ctrx_sync_on_window................................................................................................... 14
4.4.2 ctrx_sync_on_bitmap, and ctrx_sync_on_bitmap_change .......................................... 14
4.4.3 ctrx_mouse_click, ctrx_type and ctrx_key .................................................................... 15
5. Tips and tricks ................................................................................................ 16
5.1 How to show Citrix client replay in the Controller? ............................................. 16
5.2 Do not launch the Citrix sessions too quickly ...................................................... 16
5.3 How do I handle a random pop-up message? ...................................................... 16
5.4 Can a script recorded on an older version of Citrix Client be used with a new Citrix
Client? ............................................................................................................................. 17
5.5 There were no errors on the first test. Now some VUsers cannot even connect to
the application. Why? ...................................................................................................... 17
5.6 Some “ctrx_sync_on_bitmap” functions are failing and seem to be linked to a
time-out. Can this behavior be modified? ....................................................................... 17
6. Checklist and prerequisites ............................................................................ 19
7. Monitoring counters - Best practices ............................................................ 20
7.1 XenApp Performance Counters ............................................................................ 20
7.2 Tracking XenApp Growth...................................................................................... 21
7.3 Web Interface Performance Counters .................................................................. 21
7.4 Tracking Web Interface Growth ........................................................................... 22
7.5 XenDesktop Performance Counters ..................................................................... 22
7.6 Tracking XenDesktop Growth .............................................................................. 22
When deploying an application on a Citrix server-based architecture, there is always concern about
the impact on performance, availability and the scalability of the servers.
This document provides an overview of how performance testing can be carried out with HP
LoadRunner, and will focus on best practices when working with Citrix applications.
Reference:
2. FUNDAMENTALS
Citrix Systems offers a wide range of products ranging from application firewalls to virtualization. It
also offers the possibility to do application “streaming” with a product called “XenApp”. Basically, this
means a user can access an application from his PC, and use it as if it was locally installed but, in truth,
the application is running on servers in a Data Center. This feature is called “Hosted Application
Delivery” and should not be confused with “Local Application Delivery”, where a copy of the
application is copied to the client PC, and runs locally.
With application streaming, performance will mostly depend on how much ‘power’ there is on the
server-side. What are the advantages of such a technology? There are many, and here are some
examples below;
It’s easier to manage the application; only one installation is necessary on the server-side,
which means that any required updates or security patches can quickly be applied.
Users only need to have a “client” installed on their device to access any application they may
require. The application to which he has access is determined by his rights on the server-side.
This “client” allows a user to connect to the Citrix server work on his applications. It exists for different
platforms and OS, and can be obtained from the Citrix web site. Citrix Presentation Server is Windows-
based software, and only Windows-compatible applications can be deployed through it.
LoadRunner is HP’s tool for application performance testing. It generates load on the servers by
simulating the activity of many virtual users (or VUsers). It works by “capture and replay”; all actions
performed by a user are captured and translated into a scripting language, and the script obtained can
then be replayed to emulate the user actions.
Many different types of protocols can be captured and emulated by LoadRunner. For Citrix tests,
LoadRunner can simulate users interacting through Hosted Application Delivery only. This is done
capturing the communication between the Citrix Client and the Citrix Servers, and these two
communicate through the Citrix ICA protocol.
3. GETTING STARTED
It is very important to prepare and verify the LoadRunner machines before starting any type of
scripting. The Citrix-ICA script generated by LoadRunner is a GUI VUser script. This means that the
script will interact with the graphical interface of the application, and the slightest change to the
interface may result in a script error.
Changes in the interface can either come from server-side (ex: an application update), or from client-
side. In our case, every load generator and the machine used to create the scripts are considered to
be clients and because of this, it must be insured that all the following ‘settings’ are identical on all of
them.
1) Install/use the same version of the Citrix Client on all LoadRunner machines.
2) Set the same screen resolution and color depth on each of these machines. If some machines
offer only remote access, it is possible to change these settings by connecting through VNC.
3) Verify that the LoadRunner service is running with the user for which these settings were
changed.
Being a GUI-type, Citrix-ICA scripts require a lot of resources from the load generator. While a dual-
core load generator with 2 GB of RAM could easily allow many hundreds of Web VUsers to run, it will
probably only support about 25 to 40 Citrix VUsers. Keep in mind that every application has its own
footprint, and load generators should be monitored at all times during the test campaign.
Ideally, the latest version of the Citrix Client should be used during a test campaign. However, it is not
unusual to find old versions the client in companies where the tests are being carried out.
Note that the full version of the client (not the Web plugin) is required when using LoadRunner. In
version 12.1, this “full” client is known as the “Citrix Online plug-in Admin”.
If the company insists on using an older version (for policy/security issues), it is important to know
about the particularities of some versions of the clients:
As from version 11.00 of LoadRunner, versions 11.2 and 12.0 of the client are supported. The
client 11.* requires a registry patch (in fact, these registry entries are the same as the ones for
the version 10 client).
As from version 11.00 Patch 02 of LoadRunner, version 12.1 is supported. Again, a registry
patch is required, and LoadRunner is bundled with it.
Previous versions of the clients (even 10.2) have been declared “EOL” by Citrix. They should
work with LoadRunner, but it is recommended to update to a more recent and supported
versions.
As for the Citrix Servers, the latest version, called XenApp 6, is supported as from LoadRunner 11.00
Patch 02 (ie LoadRunner 11.02). Citrix XenApp Server 5 is supported as from LoadRunner 11.00.
As from version 11.51 of LoadRunner, Citrix support has been expanded as follows:
The following APIs have been added - Ctrx_Logoff: Closes the current Citrix session,
and Ctrx_Get_Server_Name: Returns the Citrix server name.
ICA file adjustment - Enables support engineers to tweak the ICA files received during Citrix
ICA + NFuse recording/replay without having to make changes on the Citrix Server Web
Interface level.
Citrix Access Gateway support: LoadRunner supports CAG for Citrix Client version 10.200 (or
less) and Citrix Client version 13.x.
Installation of the registry patch is required for the support of all versions of Citrix clients
over 10.x. Additionally, you need to install Enable_Citrix_API.reg from the LoadRunner\dat
folder on VuGen or Load Generator machines if a Citrix Client will be installed after installing
LoadRunner.
Citrix XenApp Desktop cannot be recorded with Citrix Web Access (formerly known as Citrix
NFuse) if Desktop View (Desktop Toolbar) is enabled.
Recording a Citrix NFuse script on IE9 is supported from Citrix client version 12.1.0.44.
Load Generator cannot be used in service mode for the Citrix protocol when the Citrix
XenApp client 11.2 is used. A workaround is to use another version of Citrix client.
The Citrix Connection Center may prevent record and replay of Citrix ICA scripts, if it is
running in a different user session on the same machine.
Workaround: Close all instances of the concenter.exe process for all users. To prevent the
Citrix Connection Center from starting automatically, set the ConnectionCenter registry key
to an empty value"". This key can be found at:
For 32-bit systems:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
For 64-bit systems:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\R
un
Citrix snapshots. Black snapshots may appear during record or replay when using Citrix Presentation
Server 4.0 or 4.5 (before Rollup Pack 3).
First of all, the user accounts (Citrix) should be unique. For example, if the goal is to run a test with 300
simultaneous VUsers, at least 300 Citrix accounts are required. This will allow each VUser to open a
new session, and any extra account can be used to re-run failing users from the Controller.
In the case where a user falls into error, we need to restart it manually, why there should be a number
of additional user accounts (in addition to 300 accounts). We recommend having 20% of Citrix user
accounts in addition to the 300 accounts.
A user who launches a Citrix application opens a session on the servers. Most of the time, these
sessions is maintained for a certain amount of time, after which the sessions are reset. For a real user,
this is very useful, as he can recover his work or applications in the same state when switching offices
for example. But for load tests, this feature should be modified so that VUsers can find the application
in the same state each time they launch it.
Citrix Servers configurations can also be configured to “reset” sessions when a user is disconnected or
after a session time-out. Refer to document CTX127318 for details.
4.1 Recording
There are two ways to start recording a Citrix script from the VUGen:
If you choose Citrix_ICA script, you will need to provide the login and password, and provide
the server address. If everything is entered correctly, you should be able to select the required
application from the drop-down list. It is also possible to use an ICA file.
The other way is to create a Citrix-ICA/Web script. This will first launch Internet Explorer, and
it is then necessary to login through the Citrix Web interface before launching the desired Citrix
Application.
Before recording any script, verify that you are using standard display settings (ex: 800 x 600, 1024 x
768, etc.). It is also recommended to set the same color depth on all Load Generators
The error "The coordinates you chose are illegal" can appear when using the "Insert Sync On Bitmap"
feature while editing a Citrix script in VuGen. For this reason, use one of the following screen
resolutions:
"640 x 480"
"800 x 600"
"1024 x 768"
"1024 x 744"
"1280 x 1024"
"1600 x 1200"
1) A Citrix scripts should contain at least 3 parts; the “vuser_init”, the “Action” and the
“vuser_end” sections.
If the script needs to work for many iterations, which is commonly the case, it is important to ensure
that the Action section starts and ends at the same place (screen) in the application. With this in mind,
the vuser_init section has to include steps for connecting to the Citrix servers, launching the
application, and getting to the point in the application where the iterations will start. The vuser_end
section only needs to include steps to close the application (which usually ends up closing the session).
2) For every mouse click or keyboard action resulting in a change onscreen (ex: click to obtain a
drop-down menu list), there should be a corresponding ‘image check’.
This ‘image check’ is called “Sync On Bitmap” in Citrix scripts, and tells LoadRunner what image to wait
for after a user action. Once this image appears, the script can execute the next step. If there are no
image checks, LoadRunner will simply execute all commands present in the script as fast as it can.
Take care with synchronization areas, make sure that the selected area is as representative as
possible for the proper display of a page. The synchronization must be placed at the end of each
transaction in the script. To get proper response time for any particular transaction, keep only the
synchronization function inside it without think time in between.
To insure successful bitmap synchronization, make sure that the resolution settings match. On the
recording machine, check the settings of the ICA client, the Recording Options, and the Run Time
settings. On the load generators, check the settings of the ICA client, and make sure that they are
consistent between all load generators and recording machines. If there is an inconsistency between
the resolutions, the server traffic increases in order to make the necessary adjustments.
An example of how SyncOnBitmap should be used is shown below; after searching for “c2L2” in Google,
we would like to make sure that the script will be accessing the correct site when it executes a click on
the first result. So, a SyncOnBitmap is placed just after the search to check that the first result is what
we are looking for.
Once the script has been recorded, it is easier to modify a keyboard shortcut than a mouse click which
relies on Window coordinates.
For example, instead of closing the application by using clicks to access the “File Close” option, it is
recommended to use shortcuts like “Alt + f” and “Alt + c”.
4) Remember that each user launching a Citrix application opens a terminal session on the Citrix
server.
This can be a problem when users connect for the first time to the Citrix server (or even the
application), and a “pre-run” might be necessary in some cases to initialize everything correctly.
Here are some examples of what might happen when users log in for the first time;
5) Security warnings from the Citrix Client asking whether the user allows access to local files.
These will appear on each of the load generators
6) Some applications can ask the users to set some options when they are launched for the first
time (think of welcome screens for example).
4.3
Here are the most common functions you will encounter in a Citrix script. While most of them will be
captured and generated during recording, it is important to understand how they can be modified to
avoid recording the whole business process if some changes are necessary.
Warning : all functions that starts with ctrx_synch * have a measuring frequency of 1 second, the
screens so that put less than a second may have a response time greater than or equal to one second.
4.4.1 ctrx_sync_on_window
This is a function added automatically by the VuGen during recording. As the name indicated, it waits
for a window with a certain title to appear before executing the next step.
Example:
ctrx_sync_on_window("MENU", ACTIVATE, 119, 160, 119, 118, "snapshot4", CTRX_LAST);
It is interesting to note that there are other functions like “ctrx_set_window” and “ctrx_win_exist”,
which are available to manage Windows appearing in the Citrix client. Both will check if a window with
a specific title exists in the client, and should be used when dealing with windows which vary in size
and/or position in the Citrix client.
The “ctrx_sync_on_bitmap” function can be added manually during recording, and also from existing
snapshots after recording. It waits for a bitmap to appear before executing the next step.
Example:
ctrx_sync_on_bitmap(130, 194, 114, 58, "c4929f8fc157e786e960ae69c054057c", CTRX_LAST);
On the other hand, the “ctrx_sync_on_bitmap_change” function can only be added manually after
recording. This function waits for a bitmap to change before going on to the next step. It is typically
used when dealing with a random screen (think of search results appearing) where
“ctrx_sync_on_bitmap” would be impossible to use.
Example:
ctrx_mouse_click(90, 99, LEFT_BUTTON, 0, “MENU=snapshot6”, CTRX_LAST);
ctrx_type("c2L2", "", CTRX_LAST);
ctrx_key(“DELETE_KEY”, “SHIFT_KEY”, CTRX_LAST);
In Design view Details More enter “-lr_citrix_vuser_view” in the “Command line field”. This
requires a lot of resources and should be used for debugging purposes only.
Otherwise, the Citrix Server will have problems launching the Remote Command Launcher / Launcher
Agent correctly. Usually, a 35+ second interval is recommended. This all depends on connection
method, load balancing, and the number of servers in the Citrix farm.
Requirement: the pop-up window name must be unique, and the handler function has to be placed
before calling this function.
Here is piece of code which will cause the “Enter” key to be pressed when a window with the title
“Warning!” appears.
int myHandler() {
// a bitmap sync ?
ctrx_key(“ENTER_KEY”, “0”, CTRX_LAST);
return 0;
}
Action ()
{
ctrx_execute_on_window(“Warning!”, myHandler);
... ... ...
}
No. VUGen scripts are forward compatible (HP Document ID 50181). Otherwise, it is required to re-
script the business process.
5.5 There were no errors on the first test. Now some VUsers cannot
even connect to the application. Why?
After each run, check that there are no more sessions on the Citrix servers. The “Citrix Management
Console” allows you to terminate remaining sessions. Also verify that all Citrix servers have been
configured to reset a disconnected session.
Yes, this is called the “waiting time” and by default, is set to 60 seconds for all scripts. It is possible to
change it in the “Run-time Settings”, in “Citrix Timing”.
It is also possible to change the waiting time and set different values in the script by using the
“ctrx_set_waiting_time” function. Please note that the use of this function changes the waiting time
for the rest of the script execution.
There is also an option to set a tolerance for image synchronization functions. It can be found in the
same menu as the Waiting Time, and can be set to one of the following; Exact, Low, Medium, or High.
The default value is Exact and, changing it to Low for example, would allow an image with at least 95%
match to pass the sync step.
Record the connection process into the vuser_init section, and the closing process in the
OK/KO
7 vuser_end section.
Try to use keyboard as much as possible, use mouse only when there is no
8 alternative for keyboard shortcut
This section describes the objects, counters and thresholds that are recommended to
monitor for environments running XenDesktop, XenApp and Provisioning Services. The
thresholds presented are based on real world experience but may not apply to all
environments. Organizations will need to perform their own baselining, validity testing and
validation before implementing within a production environment.
Please note that some hypervisors, such as VMware vSphere, provide specific performance
counters for tracking CPU and Memory utilization within virtual machines (i.e. “VM Processor
\% Processor Time”). These performance counters should be used instead of the counters
listed below.
Besides usual metric system (performance: CPU, Memory, Paging File), here is a list of
metrics to monitor on a Citrix server.
The following represent performance counters specific to a XenApp environment that should
be monitored in addition to ensure any issues involving XenApp performance are detected
early and addressed appropriately. Please note these counters are listed under the Citrix
MetaFrame Presentation Server object.
The following metrics should be used to track the growth of the infrastructure. Therefore
thresholds will not be discussed.
The following represent performance counters applicable to Web Interface servers that
should be monitored, in addition to the general Windows performance counters outlined earlier
within this section.
The following metrics should be used to track the growth of the infrastructure, therefore
threshold alerting do not apply.
The following metrics should be used to track the growth of the infrastructure, therefore
threshold alerting do not apply.