我们必须使我们的系统具有高度可扩展性，并且它是使用 VC++ 为 windows 平台开发的。最初说，我们想同时处理 100 个请求（来自 msmq）。最好的方法是什么？具有 100 个线程的单个进程或具有 50-50 个线程的 2 个进程？在第二种方法的情况下，除了进程内存之外还有什么好处。在Windows中首先将CPU时间分配给进程，然后在该进程的线程之间拆分，或者OS计算每个进程的线程数并根据线程而不是进程分配CPU。我们注意到在第一种情况下，CPU 利用率为 15-25%，我们想要消耗更多的 CPU。请记住，我们希望获得最佳性能，因此 100 个请求只是示例。我们还注意到，如果我们将进程的线程数增加到 120 以上，性能会因上下文切换而下降。
还有一点；我们的产品已经支持集群，但我们希望在单个节点上利用更多的 CPU。
任何建议都将受到高度赞赏。
【问题讨论】：
标签： windows multithreading process
您处理的请求数不能超过 CPU 内核数。 “快速”可扩展解决方案涉及设置线程池，其中活动（未在 IO 上阻塞）线程的数量 == CPU 内核的数量。因此，为了服务 100 个 msmq 请求而创建 100 个线程并不是好的设计。
Windows 有一个称为IO Completion Ports 的线程池机制。
使用 IO 完成端口确实会将设计推送到单个进程，因为在多进程设计中，每个进程都有自己的 IO 完成端口线程池，它将独立管理，因此您可以获得更多线程竞争CPU 内核。
IO 完成端口的“核心”理念是它是一个内核模式队列 - 您可以手动将事件发布到队列，或者通过关联文件（文件、套接字、管道）句柄来自动获取异步 IO 完成发布到它与港口。
另一方面，IO 完成端口机制会自动将事件出列到等待的工作线程 - 但如果它检测到线程池中当前的“活动”线程 >= CPU 内核数，它不会将作业出列。
使用 IO 完成端口可能会大大提高服务的可扩展性，但通常增益比预期的要小很多，因为当所有 CPU 内核都在争夺服务的其他资源时，其他因素会迅速发挥作用。
如果您的服务是用 c++ 开发的，您可能会发现对堆的序列化访问是一个很大的性能损失 - 尽管 Windows 6.1 版似乎已经实现了低争用堆，所以这可能不是一个问题。
总而言之 - 从理论上讲，您最大的性能提升将来自使用在单个进程中管理的线程池的设计。但是您严重依赖您使用的库来不序列化对关键资源的访问，这会很快失去所有理论上的性能提升。 如果您确实有库代码序列化您的线程池服务（例如由于堆争用而序列化 c++ 对象创建和销毁的情况），那么您需要更改对库的使用/切换到库的低争用版本或只是扩展输出到多个进程。
唯一知道的方法是编写测试用例，以各种方式对服务器施加压力并测量结果。
【讨论】：
Windows 上的标准方法是多线程。并不是说这始终是您最好的解决方案，但每个线程或进程都需要付出代价，并且在 Windows 上，进程更昂贵。至于调度程序，我不确定，但您可以设置进程和线程的优先级。线程的真正好处是它们共享地址空间和无需 IPC 进行通信的能力，但是必须小心保持同步。
如果您的系统已经开发（看起来是这样），那么实施多进程解决方案可能会更容易，特别是如果有可能使用多于一台机器的话。由于一台机器上的 2 个进程的 IPC 在一般情况下可以扩展到多台机器。大多数大规模并行化的尝试都失败了，因为没有评估整个系统的瓶颈。例如，如果您实现了 100 个线程，所有线程都写入同一个数据库，那么您可能在实际性能上几乎没有收获，而只是在等待您的数据库。
只是我的 .02
【讨论】：