[Высокая производительность, D] Независимый HttpBench для D, или врут ли тесты TechEmpower? (перевод)

Ответить на тему

Автор

Сообщение

news_bot ^®

Стаж: 6 лет 9 месяцев
Сообщений: 27286

news_bot ^® написал(а)
14-Окт-2020 19:43

Цитировать

Простой фреймворк для тестирования HTTP-серверов, вдохновленный Simple Web Benchmark (Прим.пер.Там есть график для многих других языков), но сфокусированный на dlang фреймворках и библиотеках.
Он измеряет достижимый RPS (запросы в секунду) в сценарии простого текстового ответа (plaintext).
Тесты были собраны или изменены из различных мест (в том числе TechEmpower).
Он использует докер-контейнер для построения и размещения сервисов и может работать локально или использовать нагрузочный тестер с удаленного хоста.
В качестве генератора нагрузки используется по умолчанию wrk и запрашивает статистику у коллектора, но hey тоже поддерживается (просто используйте ключ --tool).
Тесты можно запускать и без докера, достаточно лишь установить компиляторы для протестированных языков и генератор загрузки wrk/hey (но протестировано только на linux).
Примечание для тестов io_uring:

Для работы тестов необходимо как минимум ядро Linux 5.7.
Также возможны проблемы с пользовательскими ограничениями на залоченную память (ulimit -l) при запуске с обычным пользователем.
Наблюдается некоторая регрессия производительности, начиная с Kernel 5.7.16. См. еще баги: #189, #8.

Тесты
Тесты делятся на два типа:

singleCore — сервисы запускаются в режиме одного ядра для измерения производительности без нескольких потоков/процессов (по умолчанию).
multiCore — сервисы начинают использовать все ядра процессора хоста

Использование
Сборка контейнера дли запуска

make build — сборка контейнера
make shell — запуск контейнера
Примечание: Гувернер производительности с помощью этой команды выставляется в режим производительности.

Запуск тестов
Тупо для теста, просто запустите одну команду из (в шелле контейнера):

make all # runs all tests
make single # runs tests limited to single CPU core usage
make multi # runs tests limited to multiple CPU cores usage

Основная точка входа для продвинутых тестов находится в _suite/runner.d который представляет собой исполнимый CLI-сценарий.

_suite/runner.d list — выдать список доступных тест-бенчмарков
_suite/runner.d bench — запустить тесты
_suite/runner.d responses — выдавать ответы от каждого тестового сервиса
_suite/runner.d versions — выдать используемых перечень языков и версий в формате Markdown таблицы
Используйте _suite/runner.d -h для справки по CLI интерфейсу.

Пример:

_suite/runner.d bench --type singleCore dlang rust # запустить все тесты для dlang и rust

Тестирование удаленного хоста
Поскольку не рекомендуется использовать только локальный хост для бенчмаркинга (см. линк), CLI поддерживает выполнение тестера нагрузки с удаленного хоста.
Шаги:

на хосте, на котором будут работать серверы, войдите в шелл контейнера.
оттуда запустите что-то вроде _suite/runner.d bench --type singleCore -r foo@192.168.0.3 --host 192.168.0.2 dlang

Где -r или --remote указывает имя пользователя и имя хоста, используемое для выполнения загрузочного тестера через ssh. --host в большинстве случаев не нужен, так как CLI определяет IP хоста по маршруту по умолчанию, но он добавляется для случаев, когда он все равно нужен.
Проще сгенерировать ключ ssh и скопировать его идентификатор на хост генератора нагрузки, так как в противном случае основная команда ssh будет запрашивать пароль дважды для каждого теста (разогрев и сам тест).
Загрузочный тестер (hey) должен быть установлен на хосте нагрузочного тестера.
Хост, генерирующий нагрузку, в идеале должен быть более производительным.
Фреймворки / библиотеки
Были добавлены некоторые из топовых фреймворков с Techempower в качестве базовых точек для сравнения.
Во многих тестах в них используются различные твики, непригодные в реальных сценариях.

нет маршрутизатора (т.е. совпадение только по длине пути и т.д.)
нет парсера HTTP-запросов
предварительно собранный статический текст для ответа
и всё такое

Я постарался, по крайней мере, сделать так, чтобы размеры ответов были одинаковыми, чтобы все тесты были более честными, и хотел бы сделать больше корректировок в этом плане.
C
Эти варианты добавлены для определения потенциала конфигурации тестовой среды. Они не пытаются работать как обычные HTTP-серверы, а просто используют eventloop на максимальной скорости.
Добавлены epoll и io_uring. Оба именуются как raw.
dlang
arsd-official
Я хотел добавить эту популярную библиотеку в список для сравнения. В настоящее время используются три конфигурации внутренних http серверов:

process — форкнутый процесс, каждый из которых обслуживает один запрос.
threads — threadpool для работы с подключенными клиентами
hybrid — экспериментальная гибридная реализация только для Linux смеси форков, тредов и файберов в цикле событий.

Они добавляются в тесты singeCore, так как они не используют (на данный момент) несколько eventloop, так что мы можем сравнить этот традиционный способ (прим.пер. CGI) с другими в этой категории.
См. описание от автора — Адама.
during

raw — тест, который старается быть как можно быстрее, чтобы достичь теоретического предела используемой системы (поэтому никаких парсеров, маршрутизаторов,… — просто ивентлуп)
TBD — Используя новый асинхронный ввод/вывод io_uring, было бы интересно сравнить с наиболее часто используемой epoll на Linux-системах.

epoll
Не библиотека, а просто основной механизм опросов, используемый большинством фреймворков. Добавлено к тестированию теоретического предела системы, на котором мы измеряем — так же, как during/raw
eventcore
Библиотека, которая является основой для фреймворка vibe-d. Она обобщает цикл событий как для epoll на linux (iocp и kqueue на windows и MacOS).
Это микробенчмарк, так как он не имеет правильного http парсера, маршрутизатора или модуля построения ответов, и в настоящее время отображает только потенциал цикла событий библиотеки.

callbacks — использует только обратные вызовы для обработки событий сокета.
fibers — использует файберы для эмуляции синхронного поведения при асинхронных событиях

hunt

hunt-http — идиоматическое использование фреймворка (HTTP-маршрутизатор, парсер и все остальное)
hunt-pico — высоко специализированный и оптимизированный тест, использующий picohttpparser и настраиваемые обработчики только для тестовых целей (предварительно построенные ответы, отсутствие маршрутизатора, ...) — неудивительно, что он относительно высоко в Techempower

lighttp
Нашёл на code.dlang.org, так что тоже добавил в микс.
В нем есть парсер, маршрутизатор и генератор ответов.
mecca
Основная библиотека из Weka.
В ней используется собственная низкоуровневая реализация файберов.
Замечание: Использует некоторые хаки для доступа к внутренностям druntime, чтобы иметь возможность переключать файберы. Но она не компилируется с текущим релизом и несколькими компиляторами. Я пытался это поправить, но все еще остались некоторые проблемы.
photon
Этого нет на code.dlang.org, но это интересная библиотека, которая переписывает syscalls glibc и эмулирует их через epoll eventloop и файберы, внутри себя.
В тесте используется nodejs http-parser (не такой быстрый, как pico) и не используется маршрутизатор.
vibe-core
Библиотека более высокого уровня, использующая eventcore и добавляющая основанный на файберах фреймворк для вызова коллбэков.
По-прежнему является микробенчмарком, так как использует только TCPConnection и читает запрос построчно, а затем просто пишет статический текст ответа.
Не используется ни маршрутизатор, ни http парсер.
vibe-d
Наконец-то самый популярный веб фреймворк для dlang, который содержит все.
dotnet
В качестве сравнения используется ASP.Net Core.
В нем есть несколько настроек, упомянутых выше (упрощенный маршрутизатор, готовые текстовые ответы, ...). Прим.пер.Посмотрев код, я таки отнес его к полноценным тестам.
golang
fasthttp используется в качестве справочного.
Тест использует только HTTP парсер, но не маршрутизатор.
rust
Actix используется для сравнения в двух вариантах:

actix-web — обычное использование библиотеки
actix-raw — более тонко настраиваемый вариант с менее общеупотребительным функционалом

Результаты
Single core results (однопоточные)
Генератор нагрузки: AMD Ryzen 7 3700X 8-Core, kernel 5.8.10
Тестовая машина: Intel® Core(TM) i5-5300U CPU @ 2.30GHz, kernel 5.8.9
Сеть: 1Gbps through cheap gigabit switch
Команда тестирования: for i in 8 64 128 256; do _suite/runner.d bench --type singleCore --tool wrk -b 2 -d 120 -c $i -r tomas@10.0.0.2; done
Версии компиляторов
Язык
Версия
go
go1.15.1
ldc2
1.23.0
rust
1.48.0-nightly
dotnet
5.0.100-rc.1.20452.10
От переводчика. Полные версии таблиц с результатами можно посмотреть в оригинале. Но там все неочевидно перемешано, потому я сделал более наглядные графики по кол-ву обработанных запросов за 2 минуты (req, rps пропорционально) для двух категорий — полноценные фреймворки без твиков и все остальные, включая базовые библиотеки. И два результата — для 8 воркеров и для 256, чтобы показать масштабируемость.

И да, тесты TechEmpower, смешивая твикнутые версии с обычными, изрядно местами приукрашивают.
===========
Источник:
habr.com
===========
===========
Автор оригинала: Tomáš Chaloupka
===========Похожие новости:

Теги для поиска: #_vysokaja_proizvoditelnost (Высокая производительность), #_d, #_d_vs_c_vs_rust_vs_go_vs_c#, #_vysokaja_proizvoditelnost (
Высокая производительность
), #_d

Профиль ЛС

Ответить на тему

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы

Текущее время: 22-Ноя 23:30
Часовой пояс: UTC + 5