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

Что такое стресс-тестирование?

Хотя стресс-тестирование можно рассматривать как проведение большого количества времени с вашим малышом и маленькими детьми, на самом деле мы говорим не об этом.

С точки зрения программного обеспечения стресс-тестирование можно определить как тестирование программного обеспечения за пределами нормальной работы с целью определения критической точки. Это важно по нескольким причинам: 1) вы можете определить максимальную нагрузку 2) вы можете гарантировать, что ваше приложение будет работать в соответствии с ожиданиями.

Как вы проводите стресс-тест?

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

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

Однако сегодня мы сосредоточимся на K6.io. Это инструмент, созданный с использованием Go и JavaScript. Вы пишете тесты, используя JavaScript, а затем выполняете тесты. Поскольку они могут быть отдельными файлами, их несложно включить в рабочие процессы разработки или непрерывной интеграции. K6 — это инструмент, разработанный специально для стресс-тестирования веб-приложений.

Похвальный отзыв

K6 ни в коем случае не единственный инструмент. Я хотел кратко упомянуть еще один инструмент, который я использовал для нашего стресс-тестирования во время большого развертывания в прошлом году. Рик Страл написал инструмент под названием WebSurge, который будет вбивать URL-адрес или набор URL-адресов с заданными параметрами. Для наших конкретных целей он не содержал достаточной информации и не был достаточно настраиваемым (скриптовым), но это абсолютно хороший инструмент, которым вы можете воспользоваться.

Начало работы с К6

Стресс-тестирование веб-приложений с помощью K6 довольно просто. Это особенно верно, если у вас есть опыт работы с «современным» JavaScript. Ну, может быть, я слишком упростил это. У инструмента есть много вещей, которые он может сделать. Написание простых тестов довольно просто, как насчет этого? Ниже приведен очень простой скрипт (ссылка изменена для защиты невиновных), который мы запускаем на нашем тестовом сервере:

import http from "k6/http";
import { sleep } from "k6";
import { check } from "k6";
import { Trend } from "k6/metrics";
var myTrend = new Trend("waiting_time");
export default function () {
 let res = http.get("https://localhost/");
 myTrend.add(res.timings.waiting);
 check(res, {
  "response code was 200": (res) => res.status == 200,
  "total request time <10s": (res) => res.timings.waiting < 10 * 1000
 });
 sleep(Math.random() * 2);
};

Позвольте мне объяснить, что происходит выше. Я импортирую несколько разных частей из библиотеки K6 — http, sleep, check и Trend. Тренд будет отслеживать для меня разные вещи — в данном случае я хочу отслеживать время ожидания (сколько времени ждал каждый http-запрос). В основе кода я указываю URL-адрес, который я хочу загрузить, добавляю время результатов к тренду.

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

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

Если бы я хотел запустить этот скрипт и предполагая, что у меня установлен K6 и находится на моем пути, я мог бы выполнить его так: k6 run --vus 25 -d 60s test_script.js. Это запустит мой скрипт с 25 виртуальными пользователями на 60 секунд. Поскольку это командная строка, вы можете вместо этого направить свой вывод в файл, кстати (что мне лично нравится делать). Это может выглядеть как k6 run --vus 25 -d 60s test_script.js > test_script_results.txt. См. также Документация K6.

История (как я их нашел)

Я кратко упомянул K6 в двух разных случаях в своем блоге. Первый был при обсуждении Дросселирование запросов в веб-приложениях DotNetCore в рубрике Нагрузочное тестирование K6. Второй раз был в моей статье Использование WCF с DotNetCore под заголовком Мои выводы. Оба были довольно краткими намеками на тот факт, что мы его использовали.

Однако, чтобы расширить это, я дам небольшую предысторию. Еще в конце 2017 года я начал работать над проектом, в котором мы взяли приложение, ранее написанное на ASP.NET MVC 4 (позже преобразованное в 5), и переписали его более или менее с нуля на ASP.NET Core. Мы повторно использовали большинство внутренних сервисов и большую часть логики с предыдущего веб-сайта. В целом мы ожидали, что новый сайт будет работать лучше, чем предыдущий сайт, поскольку у .NET Core была репутация/ожидание более простой платформы.

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

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

Чтобы сделать очень длинную историю короче, мы нашли кое-что, изменили кое-что и снова передислоцировали только для того, чтобы снова потерпеть неудачу. Сделал это в третий раз и еще раз. Все вещи, которые мы нашли и изменили, были действительно хорошими изменениями, но ни одна из них не затрагивала основную проблему. Кстати, упомяну, что к этому времени я нашел и начал использовать WebSurge, и это *казалось* свидетельствовало об успехе на тестовом сервере. Именно запись в прямом эфире показывала нам, что она еще не исправлена, чем бы «это» ни было.

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

Вывод

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

Кредиты

Фото автора Tom Pumford на Unsplash

Первоначально опубликовано на https://www.seeleycoder.com 11 марта 2019 г.