具有多个应用程序池的垂直可扩展性

Question

我们正在运行一个 ASP.Net 应用程序，该应用程序还调用一些旧式 COM 对象。我们遇到一个问题，随着用户数量的增加，COM 对象正在与应用程序池在同一个线程/进程上执行，从而造成瓶颈。

我们目前已安装硬件负载平衡器并使用粘性会话来平衡 2 台服务器之间的负载。不幸的是，这似乎还不够。我们使用多个应用程序池进行了一些测试，每个应用程序池都运行相同的应用程序，性能似乎显著提高。

我有几个问题。

1. 添加多个应用程序池并全部指向相同的物理文件是否明智？
2. 我们仍将使用硬件负载平衡器。所有发往 app.xxxxxx.com 的请求都将被重定向到 app1.xxxxxx.com、app2.xxxxxx.com、app3.xxxxxx.com、app4.xxxxxx.com 等。每个请求都是同一服务器上的应用程序池。这是一种常见做法吗？
3. 服务器有 16 个核心。设置处理器亲和性是否有意义，以使每个应用程序池专用于在 4 个核心上运行？
4. 我们只能使用 InProc 会话。因此，我们甚至没有考虑使用 Web Garden。另外，据我所知，Web Garden 更多的是为了提高可用性，而不是性能。

我是一名专业开发人员，研究/执行这些任务的责任落在了我的肩上，其中很大一部分对我来说是一个学习过程。

谢谢

Answer 1

您遇到了一种相当独特的情况，即 COM 成为瓶颈，因此您无法简单地扩展。理想情况下，使用 COM 对象提高性能或用托管代码替换它们会更好地扩展，但您走在了 COM 性能解决方法的正确轨道上。

1. IIS 能够处理数百个应用程序池，所以这不是问题。每个应用程序池都会增加几 MB 的 RAM，但不会产生额外的性能开销。

2. 当然。根据应用程序池，我假设每个站点都是一个完整的站点，有自己的应用程序池。这样就很好了。

3. 如果没有必要，请不要更改处理器亲和性，因为这意味着您需要永远维护和调整它。如果 CPU 利用率相当平稳，那么默认设置就足够了。如果服务器上有其他应用程序，或者您发现存在很大的不平衡，那么请考虑处理器亲和性。不过，IIS 在大多数情况下都能很好地利用它们，因此最好让它尽可能地完成繁重的工作。

4. 正如您所说，粘性会话解决了这个问题，所以您没问题。如果您不必担心 InProc 会话状态，Web 花园可能已经解决了您的 COM 问题。另一方面，您可以考虑使用 ASP.NET 的状态服务器。让每台服务器使用本地状态服务器，并让负载平衡器使用粘性会话，每台服务器绑定 1 个。这将解决会话状态问题（只要所有内容都序列化，通常都是这样），并且它将允许您轻松地使用 Web 花园设置，而无需弄乱负载平衡器。