Какую методологию вы бы использовали для измерения грузоподъемности программного серверного приложения? - PullRequest
0 голосов
/ 04 августа 2020

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

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

Ответы [ 3 ]

1 голос
/ 04 августа 2020

Думаю, вы ищете стресс-тестирование , и сценарий будет примерно таким:

  1. Создайте нагрузочный тест, имитирующий текущее использование реального приложения

  2. Начните с текущего количества пользователей и постепенно увеличивайте нагрузку, пока

    • вы не достигнете суммы «увеличенный трафик c»
    • или начинают появляться ошибки
    • или вы начинаете наблюдать снижение производительности

    в зависимости от того, что наступит первым

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

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

Подробнее в формирование: Почему «нормального» нагрузочного тестирования недостаточно

1 голос
/ 04 августа 2020

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

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

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

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

1 голос
/ 04 августа 2020

Протестируйте продукт с одной десятой данных и трафиком c. Убедитесь, что это действие 'realisti c'.

Затем подумайте, что произойдет, когда трафик c будет расти - с RAM, диском, процессором, сетью и т. Д. c, линейно или нет. ?

Пока вы это делаете, ищите «горячие точки». Оптимизируйте их.

Будете ли вы использовать веб-страницы? Базы данных? Et c. Каждая из этих вещей масштабируется по-разному. (Другими словами, вы не предоставили достаточно подробностей в своем вопросе.)

Большинство стандартных тестов сосредоточены на одном небольшом аспекте вычислений; применение результатов к конкретному c приложению неуместно.

...