Нагрузочное тестирование

На какие факторы влияет результат нагрузочного тестирования?

• Сетевые задержки от стрессорного устройства до сервера (рекомендуется проводить тестирование в локальной сети или на локальном компьютере)
• Пропускная способность от стрессорного устройства до сервера (рекомендуется проводить тестирование в локальной сети или на локальном компьютере)
• Включен ли HTTP keep-alive (рекомендуется включать)
• Достаточно ли количество параллельных запросов (при внешнем тестировании рекомендуется открывать большее количество параллельных запросов)
• Соответствующее количество процессов на сервере (рекомендуется, чтобы количество процессов для сервиса helloworld соответствовало количеству CPU, а для базы данных — в четыре раза превышало количество CPU)
• Собственные характеристики производительности бизнеса (например, используется ли внешняя база данных)

Что такое HTTP keep-alive?

Механизм HTTP Keep-Alive — это технология, позволяющая отправлять несколько HTTP-запросов и ответов через одно соединение TCP, что сильно влияет на результаты тестирования производительности. При отключении keep-alive QPS может резко снизиться.
В настоящее время браузеры по умолчанию включают keep-alive, то есть после доступа к определенному HTTP-адресу соединение временно сохраняется и не закрывается, а при следующем запросе используется это соединение для повышения производительности.
При нагрузочном тестировании рекомендуется включать keep-alive.
Кроме того, если не включить keep-alive во время тестирования, локальный порт клиента быстро окажется в состоянии timewait, что проявляется в том, что общее количество запросов превысит определенное количество (обычно около 28,000), что приведет к возникновению неудачных запросов.

Как включить HTTP keep-alive во время нагрузочного тестирования?

Если вы используете программу ab для стресс-тестирования, нужно добавить параметр -k, например ab -n100000 -c200 -k http://127.0.0.1:8787/.
apipost нужно в возвращаемом заголовке указать gzip-заголовок, чтобы включить keep-alive (ошибка apipost, см. ниже).
Другие программы для нагрузочного тестирования обычно имеют keep-alive включенным по умолчанию.

Почему QPS очень низкий при нагрузочном тестировании через внешнюю сеть?

Высокая задержка во внешней сети приводит к низкому QPS; это нормальное явление. Например, во время тестирования страницы baidu QPS может составлять всего несколько десятков.
Рекомендуется проводить тестирование в локальной сети или на локальном компьютере, чтобы исключить влияние сетевых задержек.
Если необходимо проводить тестирование через внешнюю сеть, можно увеличить количество параллельных запросов, чтобы повысить пропускную способность (при условии достаточной пропускной способности).

Почему производительность снижается при использовании прокси-сервера nginx?

Работа nginx требует потребления системных ресурсов. Также взаимодействие между nginx и webman требует определенных ресурсов.
Однако ресурсы системы ограничены, и webman не может получить все системные ресурсы, поэтому снижение общей производительности системы является нормальным явлением.
Чтобы минимизировать влияние производительности, вызванное проксированием nginx, можно рассмотреть возможность отключения журналов nginx (access_log off;),
включить keep-alive между nginx и webman, см. nginx-прокси.

Кроме того, https требует больше ресурсов по сравнению с http, так как необходимо выполнять SSL/TLS-рукопожатия, шифрование и расшифровку данных, размер пакетов увеличивается, что требует большей пропускной способности, это может привести к снижению производительности.
Если нагрузочное тестирование происходит через короткие соединения (при отключенном HTTP keep-alive), каждое соединение требует дополнительных переговоров SSL/TLS-рукопожатий, что значительно снижает производительность. Рекомендуется проводить нагрузочное тестирование https с включенным HTTP keep-alive.

Как узнать, что система уже достигла предела производительности?

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

Почему результаты нагрузочного тестирования показывают, что производительность webman ниже, чем у фреймворка gin на go?

techempower показывает, что webman по всем показателям (чистый текст, запросы к базам данных, обновления баз данных и т. д.) в среднем превышает производительность gin почти вдвое.
Если ваши результаты отличаются, возможно, вы используете ORM в webman, что приводит к значительным потерям производительности. Попробуйте сравнить webman+原生PDO с gin+原生SQL.

Насколько снизится производительность при использовании ORM в webman?

Вот набор данных нагрузочного тестирования

Среда
Сервер Alibaba Cloud 4 ядра 4 ГБ, локальная база данных MySQL, случайный запрос одной записи из 100,000 записей, тестирование на локальном компьютере.

Если использовать原生PDO
QPS webman составляет 17,800

Если использовать Db::table() из laravel
QPS webman снижается до 9,400 QPS

Если использовать Model из laravel
QPS webman снижается до 7,200 QPS

Результаты thinkORM аналогичны, разница незначительна.

Подсказка
Хотя использование ORM приводит к снижению производительности, тем не менее для 99% бизнес-приложений производительности вполне достаточно. Если вы относитесь к тем 1%, вы можете легко решить проблему, увеличив мощность CPU или сервера.
Нам следует находить баланс между эффективностью разработки, поддерживаемостью и производительностью, а не бездумно стремиться только к производительности.

Почему QPS очень низкий при нагрузочном тестировании с помощью apipost?

Модуль нагрузочного тестирования apipost имеет ошибку: если сервер не возвращает gzip-заголовок, то невозможно сохранить keep-alive, что приводит к значительному снижению производительности.
Решение — сжать данные при возврате и добавить gzip-заголовок, например

<?php
namespace app\controller;
class IndexController
{
    public function index()
    {
        return response(gzencode('hello webman'))->withHeader('Content-Encoding', 'gzip');
    }
}

Кроме того, в некоторых случаях apipost не может обеспечить удовлетворительную нагрузку, что проявляется в том, что при одинаковом количестве параллельных запросов QPS с apipost на 50% ниже, чем с ab.
Рекомендуется использовать ab, wrk или другое специализированное программное обеспечение для нагрузочного тестирования вместо apipost.

Установка подходящего количества процессов

По умолчанию webman открывает количество процессов, равное cpu*4. На самом деле, для тестирования процессов без сетевого I/O, таких как сервис helloworld, оптимальным является соответствие числа процессов количеству ядер CPU, так как это позволяет минимизировать накладные расходы на переключение процессов.
Если вы работаете с блокирующими операциями, такими как базы данных, redis и др., количество процессов можно установить в 3-8 раз больше CPU, поскольку в этом случае необходимо больше процессов для увеличения параллелизма, а накладные расходы на переключение процессов можно игнорировать по сравнению с блокирующим I/O.

Некоторые ориентировочные значения для нагрузочного тестирования

Облачный сервер 4 ядра 4 ГБ 16 процессов локальное/внутреннее тестирование

Данные нагрузочного тестирования techempower

Примеры команд для нагрузочного тестирования

ab

# 100000 запросов 200 параллельных запросов, включен keep-alive
ab -n100000 -c200 -k http://127.0.0.1:8787/

# 100000 запросов 200 параллельных запросов, отключен keep-alive
ab -n100000 -c200 http://127.0.0.1:8787/

wrk

# 200 параллельных запросов за 10 секунд, включен keep-alive (по умолчанию)
wrk -c 200 -d 10s http://example.com