Принудительно выполнять одновременные потоки/задачи для приложения для нагрузочного тестирования С#?

Вопрос:

Есть ли способ заставить библиотеку параллельных задач выполнять несколько задач одновременно? Даже если это означает, что весь процесс будет работать медленнее со всем добавленным переключением контекста на каждом ядре?

Предыстория:

Я новичок в многопоточности, поэтому мне может понадобиться помощь. Мое первоначальное исследование не дало многого, но я также сомневаюсь, что знаю, что именно искать. Возможно, кто-то более опытный в многопоточности поможет мне лучше понять TPL и/или найти лучшее решение.

Наша компания планирует установить программное обеспечение на всех компьютерах пользователей, которое будет подключаться к центральному серверу несколько раз в день и синхронизировать некоторые файлы и данные MS Access обратно на компьютер пользователя. Мы хотели бы сначала протестировать эту концепцию под нагрузкой и посмотреть, как БД Access выдерживает множество одновременных подключений.

Мне было поручено написать приложение .NET, которое ведет себя как клиентское приложение (подключение и синхронизация с сетевым расположением), но делает это одновременно в нескольких потоках.

Я знакомлюсь с библиотекой параллельных задач (TPL), так как это кажется лучшим (новейшим) способом обработки многопоточности и легкого получения возвращаемых значений из каждого потока. Однако, насколько я понимаю, TPL решает, как выполнять каждую «задачу» для максимально быстрого выполнения, распределяя работу между доступными ядрами. Итак, скажем, я хочу запустить 30 заданий синхронизации на двухъядерной машине... TPL будет запускать 15 заданий на каждом ядре последовательно. Это означало бы, что мой нагрузочный тест будет задействовать базу данных Access не более чем с двумя подключениями одновременно. Я хочу попасть в базу данных с большим количеством одновременных подключений.


person Ben Brandt    schedule 17.08.2012    source источник
comment
Не могли бы вы рассказать, как используется эта база данных Access? # пользователей/активность?   -  person Bryan Crosby    schedule 18.08.2012
comment
около 1200 клиентских машин будут подключаться к нему (только для чтения) и запрашивать около 2000 строк данных в поисках различий между сетевой копией и их локальной копией. Это будет происходить на каждом клиенте при запуске и каждые 6 часов после этого. В среднем это одно соединение каждые 18 секунд, но мы ожидаем, что оно будет возникать волнами в течение дня.   -  person Ben Brandt    schedule 18.08.2012


Ответы (2)


Вы можете заставить TPL сделать это, указав TaskOptions.LongRunning. Согласно Reflector (но не согласно документам), это всегда создает новый поток. Я считаю, полагаться на это безопасное производственное использование.

Обычные задачи не подойдут, потому что они не гарантируют выполнение. Установка MinThreads — это ужасное решение (для рабочей среды), потому что вы изменяете глобальную настройку процесса для решения локальной проблемы. И все равно успех вам не гарантирован.

Конечно, вы также можете создавать темы. Задачи более удобны, хотя и из-за обработки ошибок. Нет ничего плохого в использовании потоков для этого варианта использования.

person usr    schedule 18.08.2012
comment
Спасибо! Я все еще учусь правильно использовать TPL, но у меня достаточно тестового кода, чтобы протестировать и убедиться, что опция .LongRunning будет делать то, что мне нужно. - person Ben Brandt; 20.08.2012

Основываясь на вашем комментарии, я думаю, вам следует в первую очередь пересмотреть использование Access. Он плохо масштабируется и имеет проблемы, когда база данных увеличивается до определенного размера. Особенно, если это просто обслуживается с какого-то общего файлового ресурса в вашей сети.

Вы можете попробовать имитировать нагрузку с вашей единственной машины, но я не думаю, что это будет очень точно представлять то, чего вы пытаетесь достичь.

Рассматривали ли вы возможность использования SQL Server Express? По сути, это перенастроенная версия полноценного SQL Server, которая может лучше соответствовать вашим потребностям.

person Bryan Crosby    schedule 18.08.2012
comment
Я полностью согласен, однако это требование навязывается нам поставщиком. Продукт поставщика разработан вокруг этой базы данных доступа как центрального источника данных. Раньше мы просто копировали обновленную базу данных доступа всем нашим клиентам при входе в систему. В последнем выпуске поставщика они добавили эту новую функцию синхронизации. Мы настроены скептически по тем же причинам, которые вы упомянули, не зная, насколько хорошо он будет работать при интенсивном использовании, поэтому мы хотим попробовать наш собственный нагрузочный тест, прежде чем развертывать его. - person Ben Brandt; 20.08.2012