Тест производительности с кешем - PullRequest
0 голосов
/ 04 декабря 2018

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

Например, запрос /data/{id}.png будет стоитьпочти 2 с в первый раз, но мы будем кэшировать ответ для последующего пользователя.При обращении к кэшу время отклика составляет 200 мс (так как мы будем выполнять некоторую легковесную операцию с кешем до ответа).

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

Поэтому мне интересно, как отразить реальную производительность для этого соответствия?

1 Ответ

0 голосов
/ 04 декабря 2018

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

Так что счастливый путь тестирование будет выглядеть примерно так:

  1. Использование ожидаемого распределения «новых» и «кэшированных» запросов
  2. Использование ожидаемогоколичество пользователей вашей системы

Этот тип тестирования производительности известен как Load Testing .Однако я не остановлюсь на этом этапе, так как нагрузочное тестирование не рассказывает всю историю .

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

И, наконец, вы можете проверить, когда(и как) ваше приложение сломается.Начните с 1 виртуального пользователя и постепенно увеличивайте нагрузку до тех пор, пока время отклика не превысит допустимые пороговые значения или не начнут появляться ошибки (что будет первым)В этот момент вы также можете знать, восстанавливается ли приложение до нормального состояния при снижении нагрузки.Этот тип тестирования известен как Стресс-тестирование , и, скорее всего, таким образом вы узнаете свое приложение Узкое место

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...