Является ли этот сценарий допустимым стресс-тестом?

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

Тем не менее, похоже, что могут быть некоторые простые улучшения. Если это должен быть длительный стресс-тест, вместо создания нового потока для каждого запроса вы можете создать пул потоков для работы (или, что еще проще, использовать пул потоков, который будет масштабироваться автоматически). Таким образом, вы должны определить тест, который, скажем, составляет 2000 пользователей, и запускает 2000 потоков, которые забивают сервер. Каждый поток, по сути, будет в цикле, который выполняет тест и повторяет его.

Другой вопрос, который неясен, - все ли ваши потоки пытаются поделиться одним файлом. Один из способов сделать это менее узким местом - хранить информацию в памяти до завершения работы программы. Или разверните поток записи, который отвечает за запись файла, и все остальные потоки предоставляют ему информацию. Если выполняется резервное копирование ввода-вывода, ваш поток-писатель будет просто хранить в памяти до тех пор, пока ввод-вывод не станет доступен, а ваши рабочие потоки тем временем могут продолжать забивать сервер. Просто имейте в виду, что из-за задействованной синхронизации потоков это может плохо масштабироваться, поэтому вы можете захотеть буферизовать некоторые записи в рабочем потоке и синхронизироваться с потоком записи файлов только один раз каждые 100 запросов. Я не думаю, что это будет большой проблемой, поскольку не похоже, что вы отслеживаете что-либо, кроме времени отклика.

Изменить: на основе комментария я бы предложил попытаться использовать один поток для управления операциями ввода-вывода в этом случае. Все ваши рабочие потоки вместо записи в файл создадут объект с любыми деталями и передадут его в очередь для записи в файл. Чтобы сократить блокировку / разблокировку, также используйте очередь в рабочем потоке и выполняйте синхронизацию только время от времени. Убедитесь, что вы действительно заблокировали, когда обмениваетесь информацией в ветке. Кроме того, я бы, возможно, посмотрел использование памяти, так как это позволит всему, что ожидает, накапливаться в памяти. Если это все еще вызывает блокировку io, я бы посмотрел либо на то, чтобы писать меньше, либо, возможно, настроить или добавить более быстрый жесткий диск.

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

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

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