В недавнем эксперименте было протестировано восемь языков программирования на сервере стоимостью $12 с одним ядром CPU и 2 ГБ оперативной памяти для определения их максимальной пропускной способности при стандартной конфигурации. В качестве базы использовались популярные фреймворки для каждого языка, СУБД PostgreSQL и веб-сервер Nginx. Целью было построить идентичный API на каждом языке и постепенно увеличивать количество виртуальных пользователей, обращающихся к нему, до тех пор, пока сервер не перестанет соответствовать заданным критериям. Наилучший результат в первоначальном тесте показал Rust с SQLite, выдержав около 14 000 одновременных пользователей.

В ответ на это было создано репозиторий на GitHub с условиями задачи, где экспертам-программистам было предложено создать наиболее производительные реализации на различных языках. Были получены реализации на 13 языках, и лучшая из них смогла поддерживать 64 000 одновременных пользователей на том же сервере за $12, что более чем в четыре раза превышает первоначальный результат.

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

Методология тестирования

Эксперимент проводился на сервере стоимостью $12 с одним общим ядром CPU, 2 ГБ оперативной памяти и 50 ГБ дискового пространства. Разработчики должны были реализовать простой API социальной сети, аналогичный Twitter, включающий пять конечных точек: получение ленты, просмотр поста, постановка лайка, создание поста и проверка работоспособности.

Каждая реализация должна была пройти набор из 42 тестов, а ответы API должны были точно соответствовать спецификации. В качестве базы данных использовался SQLite, работающий в том же процессе, что и приложение. Использование отдельных серверов баз данных, таких как Redis или PostgreSQL, или отдельных кэширующих серверов было запрещено. Каждый аутентифицированный запрос требовал проверки подписи токена входа. При создании поста или постановке лайка транзакция должна была быть зафиксирована до отправки подтверждения пользователю. Допускалось объединение нескольких операций записи в одну транзакцию, но ответ пользователю не мог быть отправлен до фиксации транзакции, что было важно для критериев задержки.

В остальном разработчики имели свободу в выборе оптимизаций: они могли использовать фреймворки, создавать собственные HTTP-серверы или отказаться от Nginx.

Для тестирования производительности использовался инструмент K6 для симуляции тысяч виртуальных пользователей. Каждый пользователь имитировал поведение реального человека: загружал ленту, просматривал посты, иногда ставил лайки или создавал посты. Количество пользователей увеличивалось до тех пор, пока сервер не переставал соответствовать требованиям. Требования к успешному прохождению уровня включали поддержание нагрузки в течение 5 минут с 95% запросов, выполненных менее чем за полсекунды, 99% — менее чем за 1 секунду, и уровнем ошибок менее 1%. Целью было измерение устойчивой производительности, а не кратковременных пиковых нагрузок.

Особенности тестирования нагрузки

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

Результаты и анализ реализаций

Были получены реализации на следующих языках: C, C++, Rust, Zig, Go, TypeScript, Python, Bun, PHP, Ruby, Erlang, Fortran и R (TypeScript на Bun). Из 28 полученных реализаций было протестировано 26. Одна реализация на C++ использовала in-memory базу данных, что нарушало правила, а другая реализация на R не смогла запуститься из-за отсутствия системной библиотеки. Заявки на Java и Node.js не были получены.

Ruby

Две реализации на Rails показали результат в 3000 и 3500 пользователей. Самая быстрая реализация на Ruby, использующая веб-сервер Iodine (написанный на C) и компилятор YJIT, достигла 14 000 пользователей. Оптимизация включала генерацию JSON-ответов непосредственно в SQLite, минуя этапы сериализации в приложении. При 14 000 пользователей P95 задержка составляла 50 мс, P99 — 154 мс, уровень ошибок — 0%, загрузка CPU — 62%. При 15 000 пользователей P99 задержка превысила 1 секунду.

Erlang

Реализация на Erlang с использованием веб-сервера Cowboy достигла 15 000 пользователей. Оптимизация включала настройку среды выполнения на один планировщик и выделение одного процесса для управления соединением с SQLite. JSON-генерация также выполнялась в SQLite. При 15 000 пользователей P95 задержка составляла 171 мс, P99 — 320 мс, загрузка CPU — 83%, использование ОЗУ — 600 МБ. При 16 000 пользователей P95 задержка превысила 4 секунды.

Python

Самая быстрая реализация на Python достигла 22 000 пользователей, что в 10 раз больше, чем в первоначальном тесте с FastAPI и PostgreSQL (2150 пользователей). Оптимизация заключалась в удалении большинства слоев фреймворка FastAPI/Starlette, позволяя запросам проходить напрямую от Uvicorn к обработчику. При 22 000 пользователей загрузка CPU составляла 91%, P95 — 353 мс, P99 — 653 мс, уровень ошибок — 0%. При 23 000 пользователей P95 задержка превысила 1 секунду.

Go

Реализация на Go достигла 22 000 пользователей. Для обработки операций с базой данных использовался один Go-рутина, который собирал до 256 запросов одновременно, выполнял операции, фиксировал транзакции и отправлял ответы. Этот метод называется "group commit". При 22 000 пользователей P95 задержка составляла 143 мс, P99 — 318 мс, уровень ошибок — 0.5%. При 23 000 пользователей уровень ошибок превысил 1%. Загрузка CPU составляла 78%, узким местом стало количество соединений.

C#

Реализация на C# достигла 32 000 пользователей. Была использована веб-сервер Kestrel с минимальным количеством промежуточных слоев. Оптимизация памяти включала использование пулов буферов для формирования JSON-ответов и выделение памяти в стеке для проверки токенов. При 32 000 пользователей P95 задержка составляла 346 мс, P99 — 731 мс, уровень ошибок — 0%. Загрузка CPU составляла 93%. При 33 000 пользователей P95 задержка превысила 1 секунду.

Fortran

Реализация на Fortran достигла 38 000 пользователей. Использовалась C-библиотека libmicrohttpd для обработки HTTP-соединений. JSON-ответы генерировались с помощью функции JSON в SQLite, а проверка токенов выполнялась через SQL-запросы. Использовался "group commit" для пакетной обработки записей в базе данных. При 38 000 пользователей P99 задержка составляла 944 мс, загрузка CPU — 85%, использование ОЗУ — 700 МБ. При 39 000 пользователей P99 задержка превысила 1.7 секунды.

PHP

Реализация на PHP с использованием Swoole (C-расширение для PHP, позволяющее запускать PHP как долгоживущий сервер) достигла 40 000 пользователей, что более чем в 50 раз превышает результат Laravel (750 пользователей) из предыдущего видео. При включенном JIT-компиляторе PHP приложение запускалось один раз, открывало соединение с базой данных и подготавливало запросы. При 40 000 пользователей P95 задержка составляла 189 мс, P99 — 853 мс, уровень ошибок — 0%. При 41 000 пользователей P95 задержка составляла 182 мс, но P99 превысила 2.4 секунды.

C

Самая быстрая реализация на C достигла 46 000 пользователей. Использовался интерфейс Linux io_uring для асинхронной обработки системных вызовов. Была оптимизирована сама библиотека SQLite путем компиляции с учетом профилирования для конкретного рабочего процесса. Запрос на получение ленты был переписан для избежания повторного подсчета лайков. Реализация показала низкое использование ОЗУ (39 МБ). При 4600 пользователях P95 задержка составляла 54 мс, P99 — 178 мс, уровень ошибок — 0%. При 47 000 пользователей P99 превысила 1 секунду. Узким местом, вероятно, было управление соединениями или внутренние очереди.

TypeScript на Bun

Реализация на TypeScript с использованием Bun достигла 47 000 пользователей. Вместо стандартного HTTP-сервера Bun использовались низкоуровневые TCP-сокеты с минимальным парсингом HTTP. JSON-ответы генерировались непосредственно в SQLite и возвращались в виде сырых байтов. Использовался повторно используемый буфер вывода и C-библиотека для увеличения бэклога соединений. При 47 000 пользователей P95 задержка составляла 96 мс, P99 — 356 мс, уровень ошибок — 0%, загрузка CPU — 72%, использование ОЗУ — 150 МБ. При 48 000 пользователей P95 задержка превысила 12 секунд.

Rust

Были получены две реализации на Rust. Первая, использующая фреймворк Axum, достигла 43 000 пользователей. Она использовала один поток с выделенной задачей для обработки базы данных и пакетной записи. При 43 000 пользователей наблюдались ошибки, а при 52 000 пользователей уровень ошибок составлял 6%. Использовалось 1.1 ГБ ОЗУ.

Вторая реализация на Rust использовала IO Uring с возможностью прямого управления сетевыми соединениями ядром ОС. Обработка записей в базе данных выполнялась пакетно. Эта реализация достигла 64 000 пользователей с P99 задержкой 224 мс, при этом загрузка CPU составляла половину, а использование ОЗУ — менее 100 МБ.

Zig

Реализация на Zig достигла 61 000 пользователей. Использовалась C-библиотека uSockets и "group commit" для пакетной обработки записей. Ограничением стало жестко заданное значение в 60 000 постоянных соединений. При 62 000 пользователей P99 задержка составляла 268 мс, уровень ошибок — 1.02%. Загрузка CPU составляла 69%.

C++

Две реализации на C++ достигли 61 000 пользователей. Одна из них, занявшая первое место, достигла 64 000 пользователей. Она использовала один поток, один цикл событий и прямой доступ к SQLite. Была оптимизирована обработка кэша страниц SQLite путем уменьшения внутреннего кэша и использования memory mapping. Операции чекпоинта были вынесены из пути обработки запросов. Эта реализация использовала режим write-ahead logging с synchronous=normal, что предполагает компромисс в долговечности данных при внезапной потере питания. При 64 000 пользователей P99 задержка составляла 910 мс, загрузка CPU — 68%.

Ключевые оптимизации

Большинство самых быстрых реализаций использовали следующие подходы:

1. Прямое обслуживание HTTP-трафика: Отказ от Nginx и использование встроенных в языки веб-серверов для минимизации накладных расходов.
2. Подготовка и повторное использование запросов к SQLite: Запросы к базе данных парсились один раз и использовались повторно с одним соединением.
3. Генерация JSON-ответов в SQLite: SQLite напрямую формировал JSON-ответы, минуя этапы сериализации в приложении.
4. "Group Commit" для пакетной обработки записей: Несколько операций записи объединялись в одну транзакцию для уменьшения накладных расходов на фиксацию.
5. Замена фреймворков: Разработчики создавали собственные серверы, системы управления памятью и циклы событий, отказываясь от стандартных фреймворков.

Компромиссы и выводы

Несмотря на впечатляющие результаты, многие из этих оптимизаций сопряжены с компромиссами, которые могут быть неприемлемы в производственных средах. Например, реализация на C++ объемом более 1300 строк кода включала собственный парсер HTTP и JSON. Быстрая реализация на Rust использовала много unsafe кода и зависела от современных функций Linux. Реализация на Bun была оптимизирована под конкретный API и менее расширяема.

"Group commit" может привести к тому, что при сбое одной транзакции могут завершиться неудачей все ожидающие запросы. Использование одного соединения с базой данных требует тщательного планирования расписания запросов, чтобы избежать блокировок.

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

Репозиторий с кодом всех реализаций доступен для ознакомления и дальнейших улучшений. Особый интерес представляют дальнейшие разработки на Java, Node.js и Go.

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