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

Question

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

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

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

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

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

PS:

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

Answer 1

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

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

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

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

Answer 2

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

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

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