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

Это подробное подробное описание. Более быструю и удобочитаемую версию см. сопутствующий пост в блоге.

1. Введение: стеки привычек и реальные рабочие нагрузки

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

Эта статья объясняет Тесты полиглотов — панель сравнения в реальном времени и открытая примеры рабочего процесса/тесты запрягать за ним — как структура принятия решений, а не таблица лидеров фанатов. Целью является доказательство, которое вы можете прикрепить к записи решения об архитектуре (ADR): одни и те же конечные точки, один и тот же генератор нагрузки, один и тот же макет контейнера, несколько языков.

Я не буду придумывать цифры пропускной способности в прозе. Когда вы запускаете эту программу, на панели мониторинга отображаются измеренные значения запросов/с и процентили задержки для этого оборудования и настройки Docker. Рассматривайте любой статический рейтинг здесь как качественные шаблоны, соответствующие семействам тестов системы и встроенной копии вердикта информационной панели.

2. Что такое тесты Polyglot?

Тесты полиглотов размещен по адресу полиглот-benchmarks.fictionally.org (Вымышленная инфраструктура в экосистеме примеров рабочих процессов). Заголовок лендинга сравнивает:

• Нгинкс нджс — Модули JavaScript внутри стандартного NGINX
• OpenResty Lua — Lua на краю OpenResty
• Python FastAPI — Приложение Uvicorn ASGI
• Зайти в сеть/http — стандартный библиотечный сервер
• Rust Actix-web — асинхронный HTTP на Actix
• булочка — Среда выполнения JavaScript с собственным HTTP-сервером
• Java (Javalin/Jetty) — облегченный HTTP JVM на Jetty
• Kotlin (Ktor/Netty) — JVM HTTP с поддержкой сопрограмм на Netty

Живой заголовок – это 8-язык сравнение: njs против Lua против Python против Go против Rust против Bun против Java против Kotlin. Подзаголовок выражает цель: производительность для длительный опрос/чат/очередь/рабочие нагрузки API — пути с интенсивным соединением, JSON и маршрутизацией, а не одна гонка на колесницах «привет, мир». Магазины JVM наконец-то получили ту же яркую поверхность, что и Go/Rust/Bun, вместо отдельного «корпоративного» анекдота.

2.1 Что показывает панель управления

Пока выполняется выполнение, пользовательский интерфейс опрашивает /data/results.json каждые две секунды и рендерит:

• Запросов/сек (пропускная способность) - совокупно из wrk за язык за тест
• Средняя задержка и Задержка хвоста P99 — в миллисекундах по модели задержки wrk
• TTFB (время до первого байта) — из синхронизации JSON скручивания вместе с wrk
• Сводная таблица — победители каждого теста с маркерами ★ на лучших ячейках
• Подробные тестовые карты — гистограммы и таблицы показателей (P50, P90, P99.9, ошибки)
• Распределение процентилей задержки — усреднено по тестам
• Вердикт — лучший вариант для вашего случая использования - повествование, когда статус complete

Эта структура намеренно удобна для ARB: диаграммы для слайдов, таблицы для электронных таблиц, описание раздела рисков ADR.

3. Набор примеров рабочих процессов

Все воспроизводимое живет под benchmarks/ в примеры рабочих процессов хранилище. Макет верхнего уровня:

benchmarks/
  bench.sh              # orchestrates tests, writes results.json
  wrk_json.lua          # wrk done() → JSON summary (RPS, percentiles)
  docker-compose.yml    # eight app services + dashboard + bench runner
  njs/                  # NGINX + njs module
  lua/                  # OpenResty nginx.conf
  python/               # FastAPI + Dockerfile
  golang/               # net/http main.go
  rust/                 # Actix-web + Cargo
  bun/                  # Bun server.ts
  java/                 # Javalin on Jetty
  kotlin/               # Ktor on Netty
  dashboard/            # static index.html + nginx.conf

3.1 Топология Docker Compose

docker-compose.yml определяет изолированные службы в общей сети:

• nginx-njs — порт 8081, конфиги отсюда ./njs
• openresty-lua — порт 8082
• python-fastapi — порт 8084, построен из ./python
• go-server — порт 8085
• rust-actix — порт 8086
• bun-server — порт 8087
• java-server — порт 8088, Javalin/Jetty от ./java
• kotlin-server — порт 8089, Ktor/Netty от ./kotlin
• dashboard — порт 8083, обслуживает HTML и монтирует results объем в /data
• bench — Альпийский контейнер, который устанавливает curl, wrk, jq, ждет зависимостей, запускает bench.sh

Бегун по скамейке делит results громкость с помощью панели мониторинга, чтобы результаты отображались в реальном времени без копирования вручную.

3.2 методология Bench.sh

Драйвер оболочки явно кодирует правила справедливости:

• Продолжительность: 10s на конечную точку на каждый язык
• Темы: 4
• Соединения: 100 одновременных
• Разогревать: 50 выстрелов /hello на каждом сервере перед тестами по времени
• На сервер: синхронизация JSON (DNS, Connect, TTFB, Total) плюс работа с wrk_json.lua

В сценарии семь тестов разделены вертикальной чертой:

Каждый язык реализует одну и ту же поверхность маршрута (см. golang/main.go, python/main.py, java/, kotlin/, конфигурации NGINX и т. д.), поэтому различия отражают среду выполнения и структуру, а не несовпадающие спецификации.

4. Почему важно «полиглот» (без фанатизма)

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

• Краевая плоскость — аутентификация, ограничения скорости, маршрутизация: Lua или njs внутри NGINX, с которым вы уже работаете
• Базовый самолет API — бизнес-логика с SLO: Go или Rust
• JVM-плоскость — существующие поместья Spring/Jakarta, общие библиотеки, глубина найма: Java (Javalin) или Kotlin (Ktor)
• Плоскость данных — ETL, блокноты, клей ML: Python
• JS-плоскость в реальном времени — WebSockets, общие типы с интерфейсом: Bun или Node, где скорость выигрывает.

Унифицированные стеки оптимизируют работу персонала и закупок. Тесты Polyglot оптимизируются подходит под рабочую нагрузку с измеримыми компромиссами на столе.

5. Размеры, которые имеют значение

Необработанные запросы/сек — это показатель, который быстрее всего распространяется в Slack. Это также легче всего неправильно прочитать. Используйте рубрику из нескольких столбцов:

6. Матрица решений

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

Прочтите сначала строку: выберите форму рабочей нагрузки, затем взвесьте столбцы. Если два критерия противоречат друг другу (например, лучший RPS против самого низкого LOC), это противоречие и является достойным обсуждения ADR.

7. Образцы корпусов (пример маркировки)

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

7.1 API чувствителен к задержке (тесты 1–2, 5–7)

JSON API и обработчики с интенсивной маршрутизацией отражают тесты 2, 5 и 7. Скомпилированные асинхронные среды выполнения (Rust Actix, Go) обычно лидируют по пропускной способности и задержке в этом классе синтетических HTTP-тестов; Бун часто придерживается сложных путей JSON с эргономикой JS. Ява (Javalin) и Kotlin (Ktor) дать JVM-командам возможность объективно сравниться с лидерами на тех же маршрутах — полезно, когда стоит вопрос «оставаться на JVM с более легким стеком» или «переписать на Go/Rust». Python FastAPI меняет количество RPS на скорость разработки — вердикт информационной панели прямо указывает на это.

7.2 Микроработа с использованием CPU (тест 3)

Фибоначчи(30) изолирует CPU без ввода-вывода. Ожидайте, что Rust и Go засияют; интерпретируемые стеки оплачивают накладные расходы; JVM JIT после прогрева может выглядеть сильнее, чем предполагает холодное окно в 10 секунд — увеличьте продолжительность, если это ваш реальный профиль. Если ваш реальный сервис связан с вводом-выводом, не переусердствуйте в этой строке — это стресс-тест для промежуточного программного обеспечения с большим объемом вычислений, а не для типичного CRUD.

7.3 Преобразование границ (тесты 6–7, варианты NGINX)

Тесты подзапроса и маршрутизации — это то, где OpenResty Lua и Нгинкс нджс принадлежность: нулевой дополнительный переход, общая рабочая память, команды эксплуатации уже управляют NGINX. В вердикте журнала рекомендуется использовать Go/Rust для основных серверных частей чата/очередей и Lua/njs на периферии — разумное разделение, которое многие предприятия уже используют неформально.

7.4 Пакетный ETL и конвейер данных

Обвязка HTTP не эмулирует нагрузки Spark или хранилища. Для пакетной обработки команды обычно отдают приоритет экосистеме и оркестрации Python (Airflow, Dagster) или работникам Go для обеспечения пропускной способности. Используйте тесты Polyglot для Поверхности и плоскости управления API эти задания раскрывают, а не сам пакетный механизм.

7.5 Быстрый внутренний инструмент

Внутренние администраторы API с низким количеством запросов в секунду и высокой скоростью изменений: Python или Bun/Node часто выигрывают по скорости и найму сотрудников. Запустите тест 2 (JSON) и тест 5 (проверка), чтобы убедиться в приемлемости накладных расходов; если количество подключений на p99 становится ниже 100, подумайте еще раз, прежде чем переходить на уровни, ориентированные на клиентов.

7.6 Имущество JVM (Java и Kotlin)

Многие предприятия уже используют Java или Kotlin для общих библиотек, инструментов обеспечения соответствия и повышения уровня найма сотрудников. Ремни безопасности java-server (Javalin на Jetty, порт 8088) и kotlin-server (Ktor на Netty, порт 8089) реализуют те же семь конечных точек, что и Go и Rust, поэтому перед перезаписью вы можете количественно оценить, является ли более легкий HTTP-стек JVM «достаточно хорошим» для данного SLO. Отдавайте предпочтение Kotlin, когда важны параллелизм в стиле сопрограмм и команды, ориентированные на Kotlin; предпочитают Java, когда окружающая среда и граф библиотеки уже ориентированы на Java. Используйте строки интерактивной информационной панели — не предполагайте, что номера Spring Boot равны номерам Javalin/Ktor.

8. Схема рабочего процесса

Воспроизводимый цикл: укажите рабочую нагрузку → запустите программу Compose → опубликуйте результаты на информационной панели Fictionally (или во внутреннем клоне) → запишите ADR с метаданными конфигурации → повторно запустите при изменении среды выполнения или оборудования.

9. Как провести собственное сравнение

1. Клон: git clone https://github.com/bwalia/workflow-examples.git && cd workflow-examples/benchmarks
2. Стартовый стек: docker compose up --build — создает все языковые образы, запускает панель управления на порту 8083, автоматически запускает стенд.
3. Смотреть: открыть http://localhost:8083 (или общедоступный сайт, если активен размещенный запуск).
4. Продлевать: добавить папку myruntime/, зеркально отразить пути к конечным точкам, зарегистрировать службу в docker-compose.yml, добавьте сервер в SERVERS в bench.sh.
5. Настроить нагрузку: редактировать DURATION, THREADS, CONNECTIONS на вершине bench.sh — документируйте изменения в вашем ADR.
6. Добавьте тесты в форме производства: например промежуточное программное обеспечение для аутентификации, запрос ORM, полезная нагрузка 50 КБ — сохраняйте четность между языками.

Для CI запустите Compose в ночном рабочем процессе, заархивируйте results.json как артефакт и не сработает только на заданных вами порогах регрессии (например, p99 +20% еженедельно за неделей в тесте 2).

10. Антипаттерны

• Выбор победителя только теста 1 — простой текст предпочитает минимальные стопки; он игнорирует JSON, CPU и проблемы с маршрутизацией.
• Игнорирование командных навыков — Ржавчина в производстве без наставников обходится дорого во времени.
• Игнорирование стоимости хостинга — Увеличение числа запросов в секунду в 2 раза бесполезно, если объем памяти на модуль удваивает ваш счет.
• Обязательное использование одного языка для всей организации — уничтожает законное разделение преимуществ и ядра.
• Замена профилирования производства — синтетический HTTP ≠ ваш ORM, кеш или региональная задержка.
• Сравнение разного оборудования — ноутбук Docker ≠ голое железо ≠ лимиты K8s; обратите внимание на класс в ADR.

11. Преимущества для инженерного лидерства

• пакеты АРБ — экспортировать скриншоты панели управления + results.json + Составить хеш.
• Независимые от поставщика доказательства — отсутствие рекламных материалов от одного поставщика облака или платформы.
• Ясность внедрения — новые сотрудники видят, *почему* сервис A — это Go, а сервис B — Python.
• Снижение риска — пилотируйте занявшего второе место в теневом сервисе, прежде чем перезаписывать.
• Беседы FinOps — связать задержку хвоста с автомасштабированием и запасом памяти.
• Дорожная карта платформы — оправдать инвестиции в навыки NGINX по сравнению с другим микросервисом K8s.

12. Ограничения

• Синтетические рабочие нагрузки — семь HTTP-тестов не могут представлять потребителей Kafka, задания GPU или сложные графики ORM.
• Докер-сеть — добавляет накладные расходы; абсолютные цифры отличаются от голого металла.
• Одиночный класс машины — размещенные результаты отражают то оборудование, которое используется вымышленно; ваши цифры будут отличаться.
• Нет слоя персистентности — эффекты базы данных и кэша изначально отсутствуют.
• Короткая продолжительность пробега — 10 секунд на тест не могут привести к паузам GC или обрывам прогрева; распространяться на кампании по борьбе со стрессом.

Сохраняйте непрерывное профилирование (eBPF, APM, нагрузочные тесты и промежуточное тестирование) как источник достоверной информации для производства. Polyglot Benchmarks сужает язык и структура дебаты с воспроизводимыми исходными данными.

13. Заключение

Смещение стека по умолчанию удобно; это также то, как команды поставляют неподходящую среду выполнения для задания. Тесты полиглотов и примеры рабочих процессов запряженный поворот «какой язык победит?» в «какой язык побеждает» для этой строки рабочей нагрузки?» — с диаграммами, которые может привести ваш АРБ.

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

Опубликовано TenthMatrix (tenthmatrix.com). Панель мониторинга производительности размещена по адресу полиглот-benchmarks.fictionally.org в экосистеме вымышленных примеров.

SEO-снимок для этой статьи

• SEO-заголовок: Тесты Polyglot: правильный инструмент для работы
• Мета-описание: Сравните njs, Lua, Python, Go, Rust, Bun, Java и Kotlin при одних и тех же рабочих нагрузках HTTP. Воспроизводимая система, живая информационная панель, матрица решений для архитекторов.
• Основные ключевые слова: полиглотные тесты, сравнение языков, архитектурные решения, примеры рабочих процессов, тест производительности, Rust vs Go, Java vs Kotlin, FastAPI, Javalin, Ktor
• Twitter/X (до 280 символов): Тесты Polyglot: те же 7 HTTP-тестов для njs, Lua, Python, Go, Rust, Bun, Java, Kotlin — живая информационная панель + набор примеров рабочих процессов. Ни одного победителя; рамки принятия решений. #Rust #GoLang #Java #Kotlin #Bunjs #polyglot
• Сообщение в LinkedIn: Мы опубликовали подробный обзор Polyglot Benchmarks — как перестать выбирать один стек для всей организации по привычке и начать сопоставлять время выполнения с рабочими нагрузками. Восемь языков (включая Java/Javalin и Kotlin/Ktor), семь сопоставимых тестов, Docker Compose + wrk, текущие результаты на сайте polyglot-benchmarks.fictionally.org, источник на github.com/bwalia/workflow-examples/tree/main/benchmarks. Включает матрицу решений, анти-шаблоны и рекомендации по ADR. От инженеров TenthMatrix. #Rust #GoLang #Java #Kotlin #Bunjs #Lua #Python #njs #FastAPI #Javalin #Ktor #OpenResty #polyglot #benchmarks