OpenResty FAQ | Сетевая структура для тестирования, функции, связанные с SSL, DSL, инструмент `ab`

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

Многие вопросы, поднятые в комментариях, являются ценными, и некоторые из наиболее типичных и интересных были специально выделены для сегодняшнего Q&A.

Давайте сегодня рассмотрим эти пять вопросов.

Вопрос 1: Как построить сетевую структуру для тестирования?

Вопрос: Должен ли клиент, запускающий wrk, находиться на машине в дополнительной сети или на машине в той же локальной сети, что и сервер? Какой из этих двух вариантов более значим для тестирования производительности?

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

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

Первый метод — развернуть wrk и серверные приложения на одной машине с хорошей производительностью. Например, мы можем включить восемь воркеров в NGINX и разделить оставшиеся ресурсы CPU между wrk, чтобы была только локальная сетевая коммуникация, минимизируя влияние сети.

Второй метод — построить локальную сеть с выделенным маршрутизатором и подключить машину, на которой находится wrk, к машине, на которой находится сервер.

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

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

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

Вопрос 2: Может ли test::nginx тестировать функции, связанные с SSL?

Вопрос: Невозможно ли тестировать функции, связанные с SSL, с помощью test::nginx?

Ответ: Это не так. test::nginx может тестировать функции, связанные с SSL; вы можете обратиться к ssl.t. Этот тестовый файл проверяет весь процесс работы SSL-сертификата. Во-первых, как вы можете видеть, тестовый пример использует код Lua для чтения открытого и закрытого ключей локального сертификата; затем он настраивает сертификат через HTTP API; наконец, он использует cosocket для выполнения SSL-рукопожатия и доступа, чтобы проверить, действителен ли сертификат.

На самом деле, не только SSL, но и функции, включенные в OpenResty, могут быть переопределены с использованием test::nginx.

Когда вы не уверены, можно ли реализовать определенную функцию с помощью test::nginx, вы можете сначала поискать тестовые примеры lua-nginx-module и других проектов OpenResty с открытым исходным кодом, и обычно вы найдете соответствующие примеры. В конце концов, test::nginx очень гибок и изменчив, и некоторые неожиданные комбинации и трюки ждут своего открытия.

Вопрос 3: Что такое DSL?

Вопрос: Что именно представляют собой DSL и test::nginx?

Ответ: DSL означает Domain Specific Language (язык, специфичный для предметной области). Цель DSL отличается от обычных языков разработки. Он предназначен не для решения задач общей области, а для задач определенной области. Самый известный DSL — это SQL, язык структурированных запросов, используемый в области баз данных.

Что касается test::nginx, это DSL, созданный для решения задач тестирования NGINX и OpenResty. На самом деле, авторы OpenResty придумали множество идей DSL и принесли много новых попыток и решений в сообщество OpenResty. Однако, как упоминалось в предыдущей статье, DSL — это обоюдоострый меч, и главный критерий для оценки ценности DSL — может ли он повысить производительность конечных пользователей.

Вопрос 4: Проблема установки test::nginx

Вопрос: После выполнения git clone, нужно ли запускать следующие команды для установки test::nginx?

cd test-nginx
perl Makefile.PL
make
sudo make install

Ответ: На самом деле, это не так. Здесь вы можете обратиться к некоторым проектам с открытым исходным кодом.

Шаг 1: установите его через менеджер пакетов

sudo cpanm --notest Test::Nginx >build.log 2>&1 || (cat build.log && exit 1)

Шаг 2: git clone последнюю версию test::nginx

git clone https://github.com/openresty/test-nginx.git test-nginx

Шаг 3: включите каталог test-nginx при использовании команды prove

prove -Itest-nginx/lib -r t

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

Вопрос 5: Хорош ли инструмент тестирования ab?

Вопрос: Как я помню, Ичунь Чжан часто упоминал ab как лучший инструмент тестирования в Google Groups?

Ответ: Как я упоминал в статье, ab не является хорошим инструментом тестирования производительности с точки зрения функций инструмента, так как он не может генерировать достаточное давление запросов. Однако производительность серверных программ сейчас мощная. Мы используем ab вместо wrk в test::nginx, потому что в режиме TEST_NGINX_BENCHMARK test::nginx использует либо ab, либо weighttp, в зависимости от версии протокола HTTP, как инструмент для тестирования производительности.

Кроме того, я надеюсь, что вы обратите внимание, что интернет-технологии меняются очень быстро, и каждому из нас нужно своевременно обновлять свои знания и навыки. Например, на мой взгляд, этот выбор test::nginx сейчас нуждается в обновлении, и Ичунь Чжан, возможно, не знал о существовании wrk в то время. Конечно, возможно, со временем появятся лучшие инструменты тестирования производительности, чем wrk, и мы должны естественно иметь позитивный и открытый ум, чтобы учиться и выбирать.

Сегодня я в основном отвечаю на вопросы, упомянутые выше. Я надеюсь, что через общение и Q&A я смогу помочь вам превратить то, что вы изучаете, в то, что вы получаете. Вы также можете поделиться этой статьей, чтобы мы могли общаться и прогрессировать вместе.