Citrix Storefront – Performance Testing and Tuning – Part 1

I’ve used the Web Capacity Analysis Tool (WCAT) in the past to measure the performance of Citrix Web Interface with some success.  So I thought this tool would be perfect for load testing Storefront.  I loaded up Fiddler, set up the WCAT extension, captured a web logon and then application launch.  The whole process looked like this:

Pretty simple right?

I logged on with Domain Passthrough authentication, I clicked on an application and I was done.  I have my customizations added in as well.  But what is actually happening?  How long does each step of the actual process take?  To determine this answer, we go to Fiddler to capture our flow so we can examine each step.

I truncated all the icon resource calling.  You can see it calls around 120 individual icon URLs.  I have my two custom ‘helpers’ (ADInfo and LogonType) that determine logon preference and whether we should get workspace control enabled or disabled (LogonType.aspx and GroupMembership.aspx).

So the actual calls to Storefront revolve around 7 unique queries to the Storefront server.  They are:

Fortunately, Citrix has documented how these need to be configured to successfully call these services.

With all this setup, I took my scenario file and executed it.  Nothing appeared to happen.  I broke down the scenario file into the individual calls and found where it was breaking.  This Citrix documentation explains it nicely:

Cross-site request forgery token

To protect against cross-site request forgery (CSRF) attacks, the Web Proxy APIs require that a CSRF token be supplied by the client, unless specified otherwise. This is a random string generated by the Web Proxy for the duration of the session and communicated to the client using a session cookie. Clients must read the value of this cookie and send it back to the Web Proxy in most API calls, as either the value of a header named Csrf-Token (note the hyphen) for POST requests, or as the value of a query string parameter named CsrfToken for GET requests.

The part in bold and underlined, is troublesome with WCAT.  WCAT does not appear to have this ability (read the value of a cookie and set a header to send it back to the web proxy).  What Storefront does, is send back a set-cookie back to the client which WCAT has no problem with…  but the data Storefront sends back is multiple values within that set-cookie command.  And this is a problem.

This is supposed to take this ‘Set-Cookie’ command and set two different values:

But what WCAT does is create a single cookie that looks like this:

WCAT creates a cookie with the entirety of a string value instead of separating them out.  Is there a way to parse this Set-Cookie command so that these are stored correctly?

Unfortunately, I was not able to find a way to do this with WCAT.

However, we can use Powershell to accomplish this job.  Ryan Butler has created a script to query the Storefront services to generate an ICA file.  This script is about 90% of what I need, however I’m not interested in doing an explicit logon, I want to do Domain Passthrough (integrateWindows) authentication, and I want to simulate the process as was captured by Fiddler, so I’ll be calling the additional services (GetUserName, AllowSelfServiceAccountManagement, etc.) and capture the time required for each section.

My Storefront Logon/Stress testing script:

And this is the output:

We can now run this script concurrently to simulate multiple clients.  Or we could run it with a command like so:

To stress an individual component.  By stressing the individual component we can actually determine which process on the Storefront server deals with which service.  So which components equals which service?

Get Auth Methods:

This component stresses “Citrix Receiver for Web”

Domain Pass-Through and Smart Card Authentication:

This component stresses “Citrix Receiver for Web” and “Citrix Delivery Services Authentication”

Resource Enumeration:

This component stresses “Citrix Receiver for Web” and “Citrix Delivery Services Resources”

Get User Name:

This component stresses “Citrix Receiver for Web”

AllowSelfServiceAccountManagement:

This component stresses “Citrix Receiver for Web” and “Citrix Delivery Services Authentication”

“GetLaunchStatus”

This component stresses “Citrix Delivery Services Resources”

LaunchIca

This component stresses “Citrix Delivery Services Resources”

Now that we have this script and we can see the where individual components cause stress, we can begin to push our Storefront server to find its limits and how the different configurations are impacted.  I’ll write up my findings on the limits of Storefront next.