У меня есть приложение определения местоположения на основе MSMQ, где я получаю обновления информации о местоположении от подразделений на местах, которые обрабатываются и помещаются в базу данных.
Процесс обновления не имеет зависимостей вне БД, поэтому мое приложение может быть настроено с переменным числом потоков. Поскольку я хочу, чтобы процесс был устойчивым при сбое, я хочу обработать столько сообщений, сколько смогу, но не больше (поэтому, если система выходит из строя, я могу забрать то, что оставил).
У меня приложение работает правильно, но я видел, что если я увеличу количество потоков, которые я использую для обработки сообщений, мое среднее число сообщений будет на одном уровне (я использую счетчики производительности для измерения этого), и я заставить систему использовать, скажем, 50% доступного процессорного времени (у меня Core i7 820QM с 4 физическими ядрами и 8 логическими ядрами), но если я вместо подъема потоков запускаю такое же количество процессов, я получаю использовать 100% процессорного времени и получать гораздо большее количество обработанных средних событий.
Может ли это быть проблемой конкуренции за блокировку? Что-то связанное с тем, как Windows 7 обрабатывает гиперпоточные процессоры? Я хотел бы понять природу проблемы, и любые указатели были бы очень признательны.
Примечание. В этом проекте я использую MSMQ, Rx и Entity Framework.