我有一位客户计划将一款应用部署到一台服务器上，并让大约 100 位用户远程桌面进入该服务器。目前计划使用 4GB RAM。
显然这个想法有些难以解释，但客户似乎愿意根据需要扩展硬件（及其许可证），并让所有人下线，在晚上进行新的部署。我的建议是使用网站而不是 winform。客户说也许以后再说。
理论上，在标准 Windows Server 硬件条件下，假设他可以扩展到 4 个 32GB 四核 HT Xeon，并且软件本身不会成为问题。
- 任何一台 Windows 服务器可以管理的最大用户数是多少？
- 当同时有多少用户时，我应该告诉他，他面临着可扩展性的噩梦？
答案1
为了准确规划容量，您需要调查应用程序的特性及其对终端造成的负载。
首先，如果这是一个关键的业务线应用程序，如果几个小时无法使用，就会造成业务损失，那么您需要考虑并行运行 2 个以上的终端服务器。跨多个终端服务器对用户进行基本负载平衡实际上非常简单，您只需执行循环 DNS 即可。这样做的好处是，如果一个 TS 因任何原因发生故障，急需访问的用户可以继续访问系统。我的建议是考虑 2 或 3 个服务器，并确保您的环境中有足够的容量来承受其中一个服务器的丢失。
至于容量/负载，请检查用户会话在运行应用程序时在 TS 上占用的内存量。将该值乘以您预计容纳的用户数，可能再添加 1 GB 供系统自己使用，然后再添加 20% 以方便使用。这就是您需要的 RAM 量，作为起点，以支持在您的 TS 上运行该应用程序的该数量的用户。您必须根据连接到实际示例 TS 会话的实际用户进行计算，因为除了应用程序本身之外，每个用户还会为其他用户进程占用额外的 RAM。这些额外的小进程加起来。
接下来，检查您的处理负载和应用程序的特性。用户是否指示应用程序运行报告，这会导致 CPU 在短时间内处于 100% 的状态？如果是这样，那就大问题了。将其扩展到 60 个用户（即使在 16 核机器上）意味着您将遇到高峰时段，其中几个人试图运行报告，每个人都会受到影响。
还要考虑系统用户所需的任何额外应用程序。用户希望将业务应用程序输出到 Excel 等办公应用程序是很常见的。他们是否能够通过共享驱动器来随机排列内容以实现此目的，或者是否需要在终端服务器本身上运行 Office。如果是这样，您需要注意：a) Office 在终端环境中的许可完全不同，并且常规版本不会安装。b) 几个 Excel 会话很快就会耗尽您的所有 RAM。
总结：跨多台服务器进行扩展，而不是在一台服务器上扩展
答案2
变量太多，无法给出明确的答案。
这是唯一的应用程序吗？它需要每个用户提供哪些资源等等。
我们在这里运行具有双四核处理器和 16GB 的 TS，最多可容纳 65 位用户运行。
答案3
理论上，你可以通过添加更多硬件来解决任何资源问题——当一台服务器不够用时，你可以添加更多服务器。但通过投入资金来维持低效的解决方案在某个时候开始变得不切实际。
一方面，将现有应用重写为可扩展服务的成本很高，因此将其部署为终端服务解决方案似乎是一条更简单的途径。但另一方面，该解决方案的可扩展性比 Web 应用等方案差得多。
首先，TS 解决方案“繁重”且持久。每个用户都会启动一组新进程，这些进程会一直持续到该用户注销，每个进程消耗的内存和处理器时间都远远超过实际应用程序所消耗的时间。当然，TS 应用程序比 Web 应用程序对服务器的依赖程度要高得多，因为所有工作（甚至渲染 UI）都是在服务器端完成的。
实际限制很难预先预测，但您应该能够在观察资源消耗的同时进行一些压力测试，以便从趋势中了解情况。但请记住，上下文切换成本只有在您同时运行大量进程时才会真正开始显现。在某些时候，根据应用程序的性质，您可能会在 CPU 饱和之前“遇到瓶颈”，而无法通过添加更多 RAM 来解决。这很难提前预测。
其次，也许更重要的是，TS 会话比客户端-服务器应用程序更容易被滥用。这种差异是如此显著，以至于人们通常甚至不会提及。如果您计划去南极旅行，人们不会费心提醒您带上保暖的衣服；同样，如果您计划向公众部署 TS 解决方案，人们会简单地假设您知道如何以各种方式保护它并为最坏的情况做好计划。这种解决方案可能变得非常糟糕的各种方式太多了，不值得一一列举。
也就是说，如果您不打算扩展那么远，那么这可能是最具成本效益的解决方案。