为什么两个进程比两个线程更有优势？
我有一个基于 MSMQ 的位置应用程序，我在其中接收来自现场单位的位置更新，并对它们进行处理并放入数据库中。
更新过程没有数据库之外的依赖项，因此我的应用程序可以配置可变数量的线程。由于我希望该过程在失败时保持稳健，因此我希望处理尽可能多的消息，但不能更多（因此，如果系统出现故障，我可以从离开的地方继续）。
我的应用程序工作正常，但我发现，如果我增加用于处理消息的线程数，我的平均消息数处于一个级别（我使用性能计数器来衡量这一点），并且我得到了系统比如说，利用 50% 的可用 CPU 时间（我有一个 Core i7 820QM，有 4 个物理核心和 8 个逻辑核心），但如果我不启动线程，而是启动相同数量的进程，我确实可以使用100% 的 CPU 时间，并获得更高数量的平均处理事件数。
会不会是锁争用问题？与 Windows 7 处理超线程处理器的方式有关吗？我希望了解问题的本质，任何指示将不胜感激。
注意：我在这个项目中使用 MSMQ、Rx 和实体框架。
I have an MSMQ based location application, where I receive position updates from units in the field and they are processed and put in a database.
The update process does not have dependencies outside the DB, so I my app can be configured with a variable number of threads. As I want the process to be robust under failure, I want to process as much messages as I can, but not more (so if the system fails, I can pick up where I left).
I have the app working correctly, but I've seen that if I raise the number of threads I use to process messages, my avg number of messages is at one level (I use performance counters to measure this), and I get the system to utilize, say, 50% of the CPU time available (I have an Core i7 820QM with 4 physical cores and 8 logical cores), but if I instead of raising threads, launch the same number of processes, I do get to use 100% of the CPU time, and get a much higher number of average events processed.
Can it be a lock contention problem? Something to do with the way Windows 7 treats hyper-threaded processors? I wish to understand the nature of the problem, and any pointers would be really appreciated.
Note: I'm using MSMQ, Rx and Entity Framework in this project.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果没有看到您的代码，很难给出准确的答案，但无论如何我都会添加一些可能性
首先，争用可能会产生巨大的影响，您使用什么锁定类型？
其次，.Net 框架会对 .Net 2.0 和 .Net 2.0 产生影响。早期的内核对象被用作锁定机制。这些需要内核转换来改变影响性能的状态。
Without seeing your code its hard to give an exact answer but I'll add some possibilities anyway
Firstly contention can have a huge impact, what locking types are you using ?
Secondly .Net framework can have an impact, for .Net 2.0 & earlier kernel objects were used as the locking mechanism. These required kernel transitions to change state which impacted performance.