Citrix XenApp Enumeration Performance – IMA vs FMA – oddities

Citrix XenApp Enumeration Performance – IMA vs FMA – oddities

/ /
in Blog

During the course of load testing FMA to see how it compares with IMA in terms of performance I encountered some oddities with FMA.  It definitely is more efficient at enumerating XenApp applications compared to IMA.  But…  The differences in my testing may have been overstated.

During the load testing I captured some performance counters.  One of them, “Citrix XML Service – enumerate resources – Concurrent Transactions” seemed to line up almost perfectly with the load wcat was applying to the broker.  BUT…  It capped out.  It seemed to cap at 200-220 concurrent connections.


The slope of the increase in the concurrent transactions should have continued but it stops.   I had set a maximum of 1000 concurrent connections via WCAT but it stops then does this weird ‘stepping’.  When this limit appears to be reached, that appears to be when the “performance” of FMA succeeds IMA significantly.


What I’m considering is that FMA is taking all requests up to that limit and then ‘queuing’ them.  I have no proof of that outside of the Perf Counter just hitting that ceiling.  And when the concurrent connections hit ~800 and the response time soared, was the broker actually working?

No.  It was not working.  The responses I got when the connections hit 800+ looked like this:

ErrorID ‘unspecified’.  Undoubtedly, it appears there is a timer somewhere that if the broker cannot respond to requests within a reasonable amount of time (20 seconds?) that it returns this error code.

So is the amount of processing the broker can handle a hardcoded limit?  I scanned the startup of the service with Procmon to see what registry keys/values the BrokerService was looking for.

I found a document from Citrix that details *some* of these registry keys.

There is a registry value that determines the maximum number of concurrent requests the FMA broker will process:

I added that key and restarted the service.  What was the impact?


Very positive.  The 800 concurrent limit was easily bypassed. Why is this limited to 500 by default?  Changing this value to 1000 had a massive improvement in terms of how many concurrent connections it could handle.  It pushed itself to 1350 concurrent connections before it broke.  If I had to push for a single tweak to FMA, this one might be it.  Mind you, the Performance Counter was still capping itself around 220 concurrent connections, so I’m not sure if that’s a limit of the counter or something else but it is VERY accurate until that point.  If I start my WCAT test and go to 50 the perf counter goes to 50.  If I choose 80, it goes to 80.  If I choose 173 it goes to exactly 173.  So it is odd.

During the course of my investigation I found a registry key that shows Citrix has decided any request over 20 seconds to the broker will fail.  This key is:

I suspect this is my “unspecified” error.  20 seconds is a really long time for a broker to respond to a request though, if you were a user this would suck.  However, is it better to increase this value?  I have it on my todo list to try and increase it for my testing to see what happens, but values like the Storefront or Netscaler XML requests to see if the brokers are responding are handicapped to 20 seconds with this value.  So it’s probably important to have them match to reduce any further timeout you may encounter.  For instance, it would not make sense to set a 60 second timeout in a Netscaler XML broker test if the broker is going to timeout at 20 seconds anyways.

Next will be testing this with Local Host Cache to see if this causes any impact.

Post a Comment

Your email address will not be published. Required fields are marked *


This site uses Akismet to reduce spam. Learn how your comment data is processed.