我有一个客户计划部署一个应用程序到一台服务器，并有100个左右的用户远程桌面到该服务器。 目前计划在4GB内存。
显然这个想法有问题需要解释，但是客户似乎愿意根据需要扩展硬件（和他的许可证），并让每个人都离线在晚上进行新的部署。 我的build议是一个网站，而不是一个winform。 客户也许晚点说。
从理论上讲，给定标准的Windows Server硬件 – 比方说，他可以扩展到四个四核的HT Xeon（32GB） – 同样，软件本身不会成为问题 –
为了准确地规划容量，您需要调查应用程序的特性以及它在terminal上的负载。
首先，如果这是一个关键的业务线应用程序，如果数小时内不能使用，就会失去业务资金，您希望查看并行运行的2+terminal服务器。 在多个terminal服务器上进行用户的基本负载平衡实际上非常简单，只需要一个循环的DNS即可。 这样做的好处是，如果一个TS由于某种原因而停止运行，那么迫切需要访问的用户可以继续访问该系统。 我的build议是查看2或3台服务器，并确保在环境中有足够的容量来承受其中一台服务器的损失。
至于容量/负载，请检查用户会话在运行应用程序时占用的内存量。 乘以你希望容纳的用户数量，为系统自己的用途增加一个Gb，然后再增加20％来获得舒适性。 这就是您需要多less内存，作为一个起点，以支持在TS上运行该应用程序的用户数量。 您必须根据连接到实际示例TS会话的实际用户进行计算，因为除应用程序本身之外，每个用户将为其他用户进程占用额外的RAM。 这些额外的小过程加起来。
接下来，检查您的处理负载和应用程序的特点。 用户是否会告诉应用程序运行报告，这可以在短时间内将CPU停留在100％？ 如果是这样，大问题。 扩展到60个用户（即使在16核心的机器上）也意味着您将有几个人试图运行报告和每个人的痛苦的高峰时间。
还要考虑系统用户所需的任何额外的应用程序。 用户想要从商业应用程序输出到Excel等办公应用程序是相当普遍的。 他们是否能够通过共享驱动器进行混洗来实现这一点，或者是否需要在terminal服务器本身上运行办公室。 如果是这样的话，您需要注意：a）办公室在terminal环境中的授权完全不同，常规版本不会安装。 b）几个Excel会话很快就吃掉了你所有的RAM。
tl; dr横向扩展到多台服务器，而不是放在一个盒子里
通往许多variables的途径来确定地回答。
这是唯一的应用程序？ 什么样的资源需要每个用户等等等等
我们在这里使用双核四核处理器来运行TS，而16GB则高达约65个用户。
从理论上讲，您可以通过添加更多的硬件来解决任何资源问题，而当一台服务器不够时，您可以添加更多的服务器。 但是，通过投资来维持低效的解决scheme在某个时候开始变得不切实际。
一方面，将现有的应用程序重写为可扩展的服务是非常昂贵的，因此简单地将其部署为terminal服务解决scheme似乎是一个更简单的途径。 但另一方面，这个解决scheme比起一个networking应用程序来，显得更加糟糕。
首先，一个TS解决scheme是“沉重的”和持久的。 每个用户都会启动一组新的进程，直到用户注销为止，每个用户都会消耗超过实际应用程序消耗的内存和处理器时间。 当然，与Web应用程序相比，TS应用程序的服务器密集程度要高得多，因为所有的工作，甚至渲染UI，都是在服务器端完成的。
实际的限制很难预测，但是你应该能够在观察资源消耗的同时做一些压力testing，从趋势中获得一个想法。 但请记住，只有同时运行大量运行进程时，才会出现上下文切换成本。 在某种程度上，根据应用程序的性质，在CPU饱和之前可能会“碰壁”，而无法通过增加更多的RAM来解决这个问题。 这是事先难以预料的。
其次，或许更重要的是，TS会话比客户机 – 服务器应用程序更容易被滥用。 差别非常大，甚至没有提到。 如果你计划去南极旅行，那么人们就不会打扰你提起暖和的衣服， 同样，如果您计划向公众部署TS解决scheme，人们会简单地假设您理解，确保每一个方式和最坏的计划。 这样的解决scheme可能会非常糟糕的各种方式是如此之多以至于不值得列举。
也就是说，如果你不打算扩展到那么远，那么这可能是你最具成本效益的解决scheme。