WCF多进程处理/设计

本文关键字：设计 处理 多进程 WCF | 更新日期: 2023-09-27 18:15:23

我目前正处于优化我们一个基于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的最佳实践是什么?如果不是(不太可能)，在我们的约束条件下，实现最佳性能的最佳方法是什么?

WCF多进程处理/设计

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

请明确一点:WCF很容易使所有cpu饱和。这个限制是由你的代码强加的。

你的建议会奏效的。也就是说，您可以为IIS应用程序池打开Web Garden模式。然后IIS将生成多个进程并将请求分发给它们。希望这个请求分布足以让您使其工作。如果还不够，可以考虑让IIS生成比cpu更多的工作进程。

这可能是一个常见的场景

这是我第一次在Stack Overflow上听到或看到它。非常罕见的。基本上，您必须在这里绕过设计错误的API。

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

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

相关文章：