JDS was engaged by a leading superannuation firm to conduct performance testing of their enterprise applications migrating to a new platform. This was part of a merger with a larger superannuation firm. The larger superannuation firm was unaware of their application performance needs and until recent times, performance was not always a high priority during the test lifecycle.
JDS was brought in to provide:
- Guidance on performance testing best practice
- Assistance with performance testing applications before the migration of each individual super fund across to the new platform
- Understanding the impact on performance for each fund prior to migration
During the engagement, there were multiple challenges which the consultants faced. Listed below are a few key challenges encountered, providing general tips for performance testing Citrix.
You should have synchronisation points prior to ANY user interaction i.e. mouse click or key stroke. This will ensure the correct timing of your scripts during replay. You don’t want to be clicking on windows or buttons that don’t exist or haven’t completely loaded yet. For example:
ctrx_sync_on_window("Warning Message", ACTIVATE, 359, 346, 312, 123, "", CTRX_LAST);
ctrx_key("ENTER_KEY", 0, "", CTRX_LAST);
Screen resolution and depth
Set your desktop colour settings to 16bit. A higher colour setting adds unneeded complexity to bitmap syncs, making them less robust. Ensure that the display settings are identical for the controller and all load generators. Use the "Windows Classic" theme and disable all the "Effects" (Fading, ClearType, etc.)
Your transactions should follow the pattern of:
- Start transaction
- Do something
- Check that it worked
- End transaction
If you synchronise outside of your transaction timers, the response times you measure will not include the time it took for the application to complete the action.
JDS recommends the following runtime settings for Citrix:
- Enable Logging = Checked
- Only send messages when an error occurs = Selected
- Extended logging -> Parameter substitution = Checked
- Extended logging -> Data returned by server = Checked
Think time should not be needed if synchronisation has been added correctly
- Ignore think time = Selected
- Error Handling -> Fail open transactions on lr_error_message = Checked
- Error Handling -> Generate snapshot on error = Checked
- Multithreading -> Run Vuser as a process = Selected
At times you may need to build your own ICA files. Create the connection in the Citrix program neighbourhood. Then get the wfclient.ini file out of C:\Documents and Settings\username\Application Data\ICAClient and rename it to an .ica file. Then add it to the script with files -> add files to script. Use the ICA file option for BPMs/load generators over the "native" VuGen Citrix login details for playback whenever possible as this gives you control over both the resolution and colour depth.
Citrix server setup
Make sure the MetaFrame server (1.8, XP, 3, or 4) is installed. Check the manual to ensure the version you are installing is supported. Citrix sessions should always begin with a new connection, rather than picking up from wherever a previously disconnected session left off, which will most likely not be where the script expects it to be.
Black screen of death
Black snapshots may appear during record or replay when using Citrix Presentation Server 4.0 and 4.5 (before Rollup Pack 3). As a potential workaround, on the Citrix server select Start Menu > Settings > Control Panel > Administrative Tools > Terminal Services Configuration > Server Settings > Licensing and change the setting Per User or Per Device to the alternative setting (i.e. If it is set to Per User, change it to Per Device and vice versa.)
A script might play back successfully in VuGen on the Load Generator; however, when running it in a scenario on the same load generator, it could fail on every single image check. This is probably a result of lossy compression—make sure to disable it on the Citrix server.
Put clean-up code in vuser_end to close the connection if the actions fail. Don't put login code in vuser_init. If the login fails in vuser_ init, you can't clean-up anything in vuser_end because it won’t run after a failed vuser_init.
JDS found performance issues with the applications during performance tests; however, these issues leaned towards functional performance issues more than volume. They were still investigated to provide an understanding of why the applications were experiencing performance problems.
The performance team then worked with action teams to assist with any possible performance resolutions, for example:
- Database indexing
- Improvements to method calls
- Improving database queries