How many sessions can you cram into a terminal server?

Question

I have a customer who plans to deploy an app to one server and have 100 or so users remote desktop into that server. It's currently planned at 4GB RAM.

Obviously there are problems to explain with this idea, but the customer seems willing to scale up the hardware (and his licenses) as needed and take everyone offline to do new deployments at night. My suggestion was a website instead of a winform. Customer said maybe later.

Theoretically, given standard Windows Server hardware -- let's say he can scale up to four quad core HT Xeons with 32GB -- And also given that the software itself doesn't become a problem --

• What is the absolute maximum number of users that any one Windows server can manage?
• At what number of simultaneous users should I tell him he's got a scalability nightmare on his hands?

Answer 1

To accurately plan capacity for this, you need to investigate the characteristics of the application and the load it'll place on the terminal.

First off, if this is a critical line-of-business app that will lose the business money if it's not available for a few hours, you want to be looking at 2+ terminal servers running in parallell. Basic load-balancing of users across multiple terminal servers is actually really easy, you just do a round-robin DNS. The benefit here is that if one TS goes down for any reason, users that urgently require access can continue to access the system. My recommendation would be to look at 2 or 3 servers and ensure you have enough capacity in the environment to withstand the loss of one of the servers.

As for capacity/load, check the amount of memory that a user's session occupies on the TS when they're running the app. Multiply that by the number of users you expect to accomodate, add maybe a Gb for the system's own use, and then add another 20% on top for comfort. That's how much RAM you need, as a starting point, to support that number of users running that app on your TS. You must calculate based on an actual user connected to an actual example TS session, because each user will occupy extra RAM for other user processes in addition to the app itself. Those extra little processes add up.

Next, check your processing load and the characteristics of the app. Do users tell the app to run reports, which can peg the CPU at 100% for a short while? If so, big problem. Scaling that up to 60 users (even on a 16-core machine) means you'll have peak times where several people are trying to run reports and everyone's suffering.

Also consider any extra apps required by the users of the system. It's fairly common for users to want to output from business apps to office applications like Excel. Are they going to be able to shuffle things via shared drives to accomplish this, or is there a requirement to run office on the Terminal Server itself. If so, you need to be aware that a) office is licensed entirely differently in a terminal environment and regular versions will not install. b) A couple of Excel sessions soon eat up all your RAM.

tl;dr scale out across multiple servers rather than up within a single box

Answer 2

Way to many variables to answer definitively.

Is that the only app? What sort of resources does it require per/user etc etc etc.

We run TS here with dual quad-core procs, and 16GB that happily have up to ~65 users running on them.

Answer 3

Theoretically, you can solve any resource problems by adding more hardware -- and when one server isn't enough, you add more servers. But sustaining an inefficient solution by feeding it money starts to become impractical at a certain point.

On the one hand, rewriting an existing app as a scalable service is expensive, so simply deploying it as a terminal services solution seems a simpler path. But on the other hand, the solution scales dramatically more poorly than something like a web app.

First of all, a TS solution is "heavy" and persistent. A set of new processes starts for each user which persist until that user logs off, each of these consumes memory and processor time above and beyond that consumed by your actual application. And, of course, a TS application is much more server-intensive than a web app because all of the work, even rendering the UI, is done server-side.

The actual limits are tough to predict up front, but you should be able to do some stress tests while watching the resource consumption to get an idea from the trends. But keep in mind that there's a context-switching cost that only really starts to become apparent when you have a whole lot of running processes all at the same time. At some point, depending on the nature of your application, you may "hit a wall" before your CPU is saturated that can't be solved by adding more RAM. This is difficult to predict ahead of time.

Second, and perhaps more importantly, a TS session is dramatically easier to abuse than a client-server application. The difference is so significant that it's often not even mentioned. If you were planning a trip to Antarctica, people wouldn't bother reminding you to pack warm clothes; likewise if you're planning on deploying a TS solution to the public, people will simply assume that you understand to secure it every which way and plan for the worst. The various ways in which such a solution could go terribly bad are so numerous that they're not worth enumerating.

That said, if you don't intend to scale out that far, then this may be your most cost-effective solution.