我们正在将新的应用程序部署到其实时环境中。
应用服务器正在运行 IIS 托管的 .NET 应用程序，该应用程序使用 EntityFramework 并对非 .NET COM+ 应用程序进行多次调用。
我们已经能够通过修改 IIS 应用程序池中的最大工作进程数来影响纯 .NET 代码的性能，但我的问题是工作进程数与组件服务中应用程序池的池大小有何关系？例如：
- 我们是否应该以这两个值之间的 1 对 1 关系为目标？
- 我们应该避免多个工作线程吗？
任何见解都值得感激...
答案1
两个池中的工作进程数量没有直接关系。您需要确定的是每个池中的停留时间。因此，如果 IIS 工作进程很忙，并且只有一小部分时间花在 COM 应用程序上，那么 COM 线程不太可能成为性能瓶颈。
尝试测量压力情况下的活动线程数，以确定如何控制各个池的大小。
还要考虑到 IIS 工作进程也会根据处理器利用率以外的标准进行回收。这可能会严重影响您在调用之间共享数据的能力，并可能破坏对直接性能产生重大影响的尝试。
最好考虑使用一个可以聚合来自单个 .NET 查询的多个请求的薄型 COM 包装器来降低执行 .NET 到 COM 桥接的成本。这还可能产生将多个 COM 方法合并到池中的单个线程中的副作用。