Windows，多个进程与多个线程

Question

我们必须使我们的系统具有高度可扩展性，并且已使用VC ++为Windows平台开发了该系统。首先说，我们想同时处理100个请求（来自msmq）。最好的方法是什么？100个线程的单个进程还是50-50个线程的2个进程？在第二种方法的情况下，除了过程存储器外，增益是多少？在Windows中，首先将CPU时间分配给进程，然后在该进程的线程之间分配，或者OS计算每个进程的线程数，然后根据线程而不是进程分配CPU。我们注意到，在第一种情况下，CPU利用率为15-25％，我们想消耗更多的CPU。请记住，我们希望获得最佳性能，因此仅以100个请求为例。我们还注意到，如果我们将进程的线程数增加到120以上，

还有一点；我们的产品已经支持集群，但是我们希望在单个节点上利用更多的CPU。

任何建议将不胜感激。

Answer 1

您无法处理的请求数超过了CPU核心数。“快速”可扩展解决方案涉及设置线程池，其中活动（在IO上未阻塞）线程的数量== CPU内核的数量。因此，由于要服务100个msmq请求而创建100个线程并不是一个好的设计。

Windows有一个称为IO完成端口的线程池机制。

使用IO完成端口确实会将设计推送到单个进程，因为在多进程设计中，每个进程将具有自己的IO完成端口线程池，可以独立管理，因此您可以获得更多争用CPU内核的线程。

IO完成端口的“核心”思想是其内核模式队列-您可以通过将文件（文件，套接字，管道）句柄与端口相关联，将事件手动发布到队列中，或自动将异步IO完成发布到该队列中。

另一方面，IO完成端口机制会自动将事件出队到正在等待的工作线程上-但是，如果它检测到线程池中当前“活动”线程> = CPU内核数，则不会出队。

使用IO完成端口可能会极大地提高服务的可伸缩性，但是通常，增益要比预期的要小得多，因为当所有CPU内核都在争用其他资源的服务时，其他因素会迅速发挥作用。

如果您的服务是用c ++开发的，则可能会发现对堆的序列化访问会降低性能-尽管Windows 6.1版似乎实现了低争用堆，因此这可能不是问题。

总结一下-理论上，您最大的性能收益将来自使用单个进程中管理的线程池的设计。但是，您非常依赖要使用的库来不序列化对关键资源的访问，这可能会很快使您失去所有理论上的性能提升。如果确实有库代码序列化了很好的线程池服务（例如由于堆争用而使c ++对象创建和销毁序列化的情况），那么您需要更改对库的使用/切换到库的低争用版本或只是扩展涉及多个流程。

唯一知道的方法是编写测试用例，以各种方式对服务器施加压力并测量结果。

Answer 2

Windows 上的标准方法是多线程。并不是说这始终是最好的解决方案，但每个线程或进程都需要付出一定的代价，并且在 Windows 上，进程的成本更高。至于调度程序，我不确定，但您可以设置进程和线程的优先级。线程的真正好处是它们的共享地址空间和无需 IPC 进行通信的能力，但必须小心维护同步。

如果您的系统已经开发出来（看起来确实如此），那么实施多进程解决方案可能会更容易，特别是如果有可能使用多于一台机器的话。一般情况下，一台机器上的 2 个进程的 IPC 可以扩展到多台机器。大多数大规模并行化的尝试都失败了，因为没有对整个系统进行瓶颈评估。例如，如果您实现 100 个线程，所有线程都写入同一个数据库，您可能在实际性能上获得很少的收益，而只是等待数据库。

只是我的.02