我们正在将新应用程序部署到其实时环境中。
应用程序服务器正在运行使用EntityFramework的IIS托pipe的.NET应用程序，并对非.NET COM +应用程序进行了多次调用。
我们已经能够通过修改IIS应用程序池中最大工作进程的数量来影响纯.NET代码的性能，但是我的问题是工作进程的数量与组件服务中应用程序池的池大小有什么关系？ 像：
任何洞察力感激地收到…
两个池中的工作进程数量不直接相关。 你需要build立的是在每个池中的停留时间。 所以，如果IIS工作人员很忙，COM应用程序只花费了很less的总体时间，那么COM线程不可能成为瓶颈。
尝试测量压力情况下活动线程的数量，以确定如何控制单个池的大小。
还要考虑到IIS工作进程也在处理器利用率以外的条件下被回收。 这可能会大大影响您在调用之间共享数据的能力，并可能会破坏强烈影响直接性能的尝试。
通过考虑一个可以聚合来自单个.NET查询的多个请求的精简COM包装器，可以更好地降低.NET到COM桥接的成本。 这也可以将多个COM方法合并成一个池中的单个线程的副作用。