Overview
It’s been a while since we’ve published scalability numbers on StoreFront, so I wanted to broadcast an update for 3 reasons:
- A ton has changed from two years ago since we last did testing on StoreFront 2.0 (Planning Guide here)
- More and more customers are now migrating from Web Interface to StoreFront
- We have made some interesting discoveries and the Community has the right to know!
Receiver for Web vs. Native Receiver
One of the most important discoveries we made in the lab was the difference in StoreFront scalability as it relates to which “flavor” of Receiver is used. Specifically, Receiver for Web vs. Native Receiver. We found that a pure Native Receiver environment can improve scalability by up to 30% and requires 35% less CPU compared to Receiver for Web. So it’s really important to understand which method your users will be leveraging and plan accordingly.
Memory
Another thing we didn’t quite see coming was the impact on memory usage on the StoreFront servers when using Receiver for Web. We found that Receiver for Web requires an additional 3 KB per resource, per user. This can obviously increase your memory requirements quite a bit if you have a lot of applications and users. As a reminder, we recommend at least 3 GB of memory as a baseline for StoreFront 2.6 (4 GB in 3.0, which I’ll talk about in the next article).
Nodes in a Server Group
When we started looking at internal mechanisms like the Credential Wallet and testing complex replication schemes with dozens of StoreFront nodes in the same group, we also made some interesting discoveries. We came to the conclusion that it is best to limit the number of StoreFront nodes in a group to 5 servers. Now, keep in mind there is no technical limit or cap that we enforce – it’s just similar to the guidance we’ve provided regarding zones and IMA in the past (fewer is better and we really don’t recommend more than 5 zones in a farm, but there is actually no upper limit). What happens if you need more? Well, there are some things you can do in terms of scaling “up” (vs. “out”) that I’ll talk about in the next section. But I doubt most customers will need to scale beyond 5 servers at any site, especially when I reveal the updated numbers in the next section.
Single Server Scalability (StoreFront 2.6)
Yes, I realize StoreFront 3.0 has been released and I’m planning a follow-up article in a few weeks once we complete our internal testing. But we can still learn a lot from the 2.6 numbers. And this time around we looked at really pushing the limits of a single StoreFront server to determine how we should go about deploying this critical infrastructure component in a global enterprise with hundreds of thousands of users (when we did the first round of testing 2.5 years ago with StoreFront 2.0, we really only looked at scenarios with 10k users). So this time we bumped up the test harness to 40k users and we logged in all users within 15 minutes (sustaining 44 requests per second). We also did another test to see if we could log in users even faster and we were able to sustain 100 requests per second. But here is ultimately what we found in terms of Single Server Scalability:
- A single 2 vCPU server can comfortably support 32,000 user connections per hour using Receiver for Web.
- If we scale “up” by adding additional CPU to a StoreFront VM, a single 16 vCPU server can support 110,000 user connections per hour. 5 nodes can theoretically support 337,000 connections per hour, although we’ve never scaled that high in a customer environment.
- If we scale “out” by adding additional 2 vCPU nodes, a 5 node group can support 160,000 connections per hour.
- It is important to note that the scalability is non-linear when you add vCPUs or nodes. All of these numbers are also based on a single site/farm – aggregation of multiple sites is a topic for another day.
Sizing & Deployment Guidance
As you can probably tell, we did a ton of different tests with single nodes and multiple nodes and varying CPU configurations (we literally tested 2, 4, 6, 8 and 16 vCPUs). And some of the numbers I shared above are certainly impressive, but you may be asking what should I do 80% of the time and where should I start in terms of sizing? Here is what our Consulting team has been doing in the field most of the time over the last year or so:
- The sweet spot for a single StoreFront VM seems to be 4 vCPUs and 8 GB RAM. The sweet spot for a server group seems to be 2 or 3 nodes. So start with 2 StoreFront VMs with those specs and you’ll be able to comfortably handle about 150,000 user connections per hour. If you need additional capacity or will have truly extreme logon storms, then add another node with those same specs to the group – that will get you over 200,000 connections or so. Put these StoreFront nodes behind a NetScaler and you’re off and running.
- Make sure you account for the flavor of Receiver used! That 150k number in the previous bullet is actually about 140k for RfW and 190k for Native Receiver. So it really does matter how your users will be accessing the StoreFront infrastructure.
Hopefully, you found this info valuable – maybe next time we’ll share some of the latest testing we’ve been doing around XenApp 7.6 with various graphics modes/codecs and 2012 R2 (in addition to an update on StoreFront 3.0 scalability as I mentioned earlier). Special thanks to our System II (large scale) Test team in the UK led by Martin Rowan – most of the numbers in this article are from the testing conducted by Martin’s team, so we really owe him one.
Cheers, Nick
Nicholas Rintalan, Lead Architect – Americas, Citrix Consulting Services (CCS)