我们正在运行一个ASP.Net应用程序，它也调用一些传统的COM对象。 我们遇到了一个问题：用户数量增加COM对象正在创build一个瓶颈，因为它在与应用程序池相同的线程/进程上执行。
我们目前有一个硬件负载平衡器，并使用粘性会话来平衡两台服务器之间的负载。 不幸的是，这似乎还不够。 我们使用多个应用程序池进行了一些testing，每个应用程序池都运行相同的应用程序，性能似乎有显着提高
我有几个问题。
我是一个贸易的开发者，而且我研究/执行这些任务，其中很多是我的一个学习过程。
谢谢
你有一个相当独特的情况，COM成为一个瓶颈，所以你不能简单地扩大规模。 理想情况下，使用COM对象提高性能或者用托pipe代码替代它们会更好地缩放，但是您正处于COM性能解决scheme的正确轨道上。
IIS能够处理数百个应用程序池，所以这不是问题。 它将为每个应用程序池添加几MB的RAM，但不会增加额外的性能开销。
当然。 通过应用程序池，我认为每个应用程序池都是拥有自己的应用程序池的完整网站。 这很好。
如果你不需要，不要改变处理器的亲和力，因为这意味着你需要永远维护和调整它。 如果CPU利用率非常平坦，那么你就可以使用默认设置。 如果您在服务器上有其他应用程序，或者如果您看到很大的不平衡，请考虑处理器亲和力。 虽然IIS在很大程度上利用了它们，但是如果可能的话，最好还是让它做大量的工作。
正如你所说，粘性会议解决，所以你很好。 Web花园可能已经解决了您的COM问题，如果您没有InProc会话状态担心。 作为一个方面，你可以考虑使用ASP.NET的状态服务器。 让每个服务器使用本地状态服务器，并使负载均衡器使用每个服务器1个绑定的粘性会话。 这将解决会话状态（只要序列化，通常它会），它可以让你轻松地使用networking花园设置，而不必弄乱负载平衡器。