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

Question

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

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

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

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

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

PS:

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

Answer 1

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

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

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

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

Answer 2

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

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

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