WCF多流程处理/设计

Question

我目前正处于优化基于WCF的服务的设计阶段。该服务向一组不是线程安全的库提供包装API。API还需要很长时间才能完成(平均0.5秒)。在单个批处理运行时，可能会发生数十万次调用。

当前端点导致12%-15%的CPU利用率(8核心)令人失望，大概是因为只有一个线程来服务调用。库不是线程安全的，唯一的解决方案似乎是创建多个进程，每个进程都公开一个端点。

我们必须保留“原始”端点，这样客户端接口将是相同的：

Client Thread --> +---------+   +-----------------+ <--> Worker Process 1
Client Thread --> | Service |-->| "Worker Process | <--> Worker Process 2
Client Thread --> | API     |   | Manager"        | <--> Worker Process 3
Client Thread --> +---------+   +-----------------+ <--> Worker Process 4

以下是我目前的想法：

1. 原始端点将转发对“辅助进程管理器”的调用。
2. 这个“管理器”将有一个线程池，然后调用每个工作进程。这个呼叫是一个阻塞呼叫。
3. 每个工作进程都公开一个(几乎)相同的端点。(可能是通过命名管道)。
4. 原始服务API将更改为每个调用实例的上下文(现在是单个的)。

这可能是一个常见的场景，所以我想知道在这种情况下WCF的最佳实践是什么？如果不是(不太可能)，考虑到我们的限制，实现最佳性能的最佳方法是什么？

Answer 1

我继续设计，并能够达到100%的CPU利用率。代码需要从服务主机(而不是UI主机)运行，以获得好处。

希望这对遇到同样情况的人有帮助。

Answer 2

当前端点导致12%-15%的CPU利用率(8核心)令人失望，大概是因为只有一个线程来服务调用。

只需明确这一点: WCF很容易使所有CPU饱和。此限制是由您的代码强加的。

你的建议会奏效的。尽管如此，您可以为该IIS应用程序池打开网络花园模式。IIS将生成多个进程并将请求分发给它们。希望此请求分发甚至足以使其正常工作。如果还不够，可以考虑让IIS生成比CPU更多的工作进程。

这可能是一个常见的情况。

我第一次听说这个，或者在堆栈溢出上看到它。非常罕见。基本上，您必须在这里处理一个设计错误的API。