Windows，多进程与多线程

Question

为了使我们的系统具有高度的可扩展性，我们已经使用VC++为windows平台开发了该系统。假设最初，我们希望同时处理100个请求(来自msmq)。最好的方法是什么？单进程有100个线程，还是2个进程有50-50个线程？在第二种方法的情况下，除了进程内存之外，还有什么好处。在windows中，CPU时间首先分配给进程，然后在该进程的线程之间分配，或者OS计算每个进程的线程数，并根据线程而不是进程来分配CPU。我们注意到，在第一种情况下，CPU利用率为15-25%，我们希望消耗更多CPU。请记住，我们希望获得最佳性能，因此仅举100个请求为例。我们还注意到，如果我们将进程的线程数增加到120以上，由于上下文切换，性能会下降。

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

任何建议都将受到高度赞赏。

Answer 1

windows上的标准方法是多线程。这并不是说这总是你最好的解决方案，但每个线程或进程都要付出代价，而在windows上，进程的代价更高。至于调度器，我不确定，但你可以设置进程和线程的优先级。线程的真正好处是它们共享的地址空间和在没有IPC的情况下通信的能力，但是必须小心地保持同步。

如果您的系统已经开发好了(看起来是这样)，那么实现多进程解决方案可能会更容易一些，特别是在有机会使用多台机器的情况下。因为通常情况下，一台机器上的两个进程的IPC可以扩展到多台机器。大多数大规模并行化的尝试都失败了，因为没有对整个系统进行瓶颈评估。例如，如果您实现了100个线程，所有线程都写入同一数据库，那么您可能几乎不会获得实际性能，而只是等待您的数据库。

只有我的.02

Answer 2

你不能处理比CPU核心更多的请求。“快速”可伸缩的解决方案包括设置线程池，其中活动(IO上未阻塞)线程的数量与CPU核心的数量相同( == )。因此，创建100个线程是因为您希望为100个msmq请求提供服务，这不是一个好的设计。

Windows有一种称为IO Completion Ports的线程池机制。

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

IO完成端口的“核心”思想是它是一个内核模式队列--您可以手动将事件发送到队列，或者通过将文件(文件、套接字、管道)句柄与端口关联来自动向其发送异步IO完成。

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

使用IO完成端口可能会极大地提高服务的可扩展性，但通常情况下，当所有CPU核心都在争夺服务的其他资源时，由于其他因素会迅速发挥作用，因此收益会比预期小得多。

如果您的服务是在c++中开发的，您可能会发现对堆的序列化访问是一个很大的性能损失-尽管Windows6.1版似乎实现了低争用堆，因此这可能不是什么问题。

总而言之，从理论上讲，您最大的性能增益将来自使用在单个进程中管理的线程池的设计。但是，您严重依赖于您正在使用的库，无法序列化对关键资源的访问，这可能会很快失去所有理论上的性能收益。如果您的库代码序列化了很好的线程池服务(就像c++对象创建和销毁由于堆争用而被序列化的情况一样)，那么您需要将库的使用/切换更改为低争用版本的库，或者只是向外扩展到多个进程。

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