This blog is continuation to my last blog ‘Citrix Protocol on LoadRunner – Tips and Tricks Part 1’. In this article, I will discuss more tips that can be helpful when working with the Citrix_ICA protocol and LoadRunner.
Number of vusers per LoadGenerator Machine:
A LoadGenerator machine can run only a limited number of Citrix Vusers at the same time. This is due to the graphic limitations of that machine. This limits the performance load that be applied to the application. To solve this problem and increase the number of vusers per machine –
1. Open a terminal server session on that machine.
2. Call this terminal server session as a new Virtual-user injector machine.
3. Connect to this new virtual injector machine from controller. To connect, use respective machine names e.g. Machine_001, Machine_002, etc (Or) respective IP Addresses.
4. Use these additional machines as LoadGenerators.
IP Spoofing characteristics With Citrix
Some applications restrict users to only one IP address and hence require a unique IP address for every virtual user. This feature is enabled for application security, session pooling or many other reasons. LoadRunner’s IP Spoofing is not supported for Citrix Protocol. However, each Citrix session can be configured to use a different IP address by making configuration-setting changes on the Citrix Presentation Server.
For Citrix version 4.5, by referring to tutorial downloaded with the application, one can find this information in the 4th chapter, which is “Using Virtual IP Addresses with Published Applications”. The Citrix administrator’s presence is important here since, these configuration changes require registry changes on the server.
Pointing appropriately to the correct ICA file:
Connection should be configured appropriately to point to the correct ICA file. If Windows authentication keeps popping up, it is likely to be because of the Active Directory’s inability to authenticate the user. The ICA files may be located in current user’s profile but not in Virtual buy capsiplex user’s profile. Hence while replaying or executing test, the vuser will not be able to point to the ICA file. This will cause script replay to fail.
Usage of Web_set_user function for Multi-protocol Citrix + Web script –
In case of multiprotocol script, NTLM authentication is required to be provided. In the case of NTLM authentication or proxy server, domain name, user id, password and post port with appropriate information is required to be added. In such cases web_set_user() function should be used –
web_set_user("DomainName\UserID", "password", "host:port");
Dynamic Synchronization for Bitmap Changes
For transactions that involve data-entry, synchronization of bitmaps while changing menus, tabs and windows is necessary to ensure that exact menu/tab/window loads successfully. For the free flow of performance scripting, identifying when a bitmap changes. This allows the script to wait until an application process is finished. The LR function that allows monitoring of the bitmap changes is “ctrx_sync_on_bitmap_change”.
The syntax of this function is:
ctrx_sync_on_bitmap_change (x_start, y_start, width, height, <optional arguments>, CONTINUE_ON_ERROR] CTRX_LAST);
During script execution, this function sets the value of the defined bitmap and waits for it to change. At times, bitmap changes before the call to wait is made. In such cases, it becomes necessary for the script to set the value of the bitmap before initiating the command that changes it. Inserting original bitmap value in the ctrx_sync_on_bitmap_change function helps here. If the bitmap has not changed, ctrx_sync_on_bitmap_change will wait until the bitmap changes, otherwise it continues as normal. If a predetermined bitmap value is used, all arguments for the function will be required. The syntax of the function is:
ctrx_sync_on_bitmap_change(x_start, y_start, width, height, initial wait time, timeout, bitmap value, CTRX_LAST);
In my next article, I will discuss more points that will help performance test engineers working on Citrix protocol.