Эмпирическая база: почему корутины в одном потоке работают

Утверждение о том, что однопоточная кооперативная конкурентность эффективна для IO-bound нагрузок, подтверждается измерениями, академическими исследованиями и опытом эксплуатации крупных систем.

1. Стоимость переключения: корутина vs поток ОС

Главное преимущество корутин — кооперативное переключение происходит в пользовательском пространстве, без обращения к ядру ОС.

Измерения на Linux

Источники:

• Eli Bendersky, Measuring context switching and memory overheads for Linux threads (2018) — прямые измерения стоимости переключения потоков Linux и сравнение с goroutines
• Jim Blandy, context-switch (Rust benchmark) — async-задача переключается за ~0.2 µs vs ~1.7 µs у потока (8.5x быстрее), создаётся за 0.3 µs vs 17 µs (56x быстрее), занимает 0.4 KiB vs 9.5 KiB (24x меньше)

Что это означает на практике

Переключение корутины стоит ~200 наносекунд — это на порядок дешевле, чем переключение потока ОС (~1.5 µs). Но ещё важнее, что переключение корутины не вызывает косвенных расходов: сброс TLB-кэша, инвалидация branch predictor, миграция между ядрами — всё это свойственно потокам, но не корутинам в одном потоке.

Для event loop, обрабатывающего 80 корутин на ядро, суммарные расходы на переключение составляют:

80 × 200 ns = 16 µs на полный цикл обхода всех корутин

Это ничтожно мало по сравнению с 80 ms ожидания I/O.

2. Память: масштаб различий

Потоки ОС выделяют стек фиксированного размера (по умолчанию 8 MiB на Linux). Корутины хранят только своё состояние — локальные переменные и точку возобновления.

Источники:

• Kotlin Coroutines vs Threads Memory Benchmark (TechYourChance) — соотношение 6:1 по памяти
• Super Fast Python: Coroutines Use Less Memory Than Threads — сравнение в Python
• Go FAQ: goroutines — динамический стек goroutine

Следствие для веб-серверов

Для 640 конкурентных задач (8 ядер × 80 корутин):

• Потоки ОС: 640 × 8 MiB = 5 GiB виртуальной памяти (реально меньше благодаря lazy allocation, но давление на планировщик ОС значительное)
• Корутины: 640 × 4 KiB = 2.5 MiB (разница — три порядка)

3. Проблема C10K и реальные серверы

Проблема

В 1999 году Дэн Кегел сформулировал проблему C10K: серверы с моделью «один поток на соединение» не способны обслужить 10 000 одновременных подключений. Причина не в аппаратных ограничениях, а в overhead потоков ОС.

Решение

Проблема была решена переходом к event-driven архитектуре: вместо создания потока на каждое соединение, один цикл событий (event loop) обслуживает тысячи соединений в одном потоке.

Именно этот подход реализуют nginx, Node.js, libuv, и — в контексте PHP — True Async.

Бенчмарки: nginx (event-driven) vs Apache (thread-per-request)

nginx обслуживает в 2–4 раза больше запросов, чем Apache, при этом потребляя значительно меньше памяти. Apache с thread-per-request архитектурой принимает не более 150 соединений одновременно (по умолчанию), после чего новые клиенты ждут в очереди.

Источники:

• Dan Kegel, The C10K problem (1999) — постановка проблемы
• Nginx vs Apache: Web Server Performance Comparison (2025) — бенчмарки
• Cloudflare: How we scaled nginx — промышленный опыт

4. Академические исследования

SEDA: Staged Event-Driven Architecture (Welsh et al., 2001)

Мэтт Уэлш, Дэвид Каллер и Эрик Брюер из UC Berkeley предложили SEDA — серверную архитектуру, основанную на событиях и очередях между стадиями обработки.

Ключевой результат: SEDA-сервер на Java превзошёл по пропускной способности Apache (C, thread-per-connection) при 10 000+ одновременных соединений. Apache не мог принять более 150 соединений одновременно.

Welsh M., Culler D., Brewer E. SEDA: An Architecture for Well-Conditioned, Scalable Internet Services. SOSP ‘01 (2001). PDF

Сравнение архитектур веб-серверов (Pariag et al., 2007)

Наиболее тщательное сравнение архитектур провели Pariag et al. из University of Waterloo. Они сравнили три сервера на одной кодовой базе:

• µserver — event-driven (SYMPED, один процесс)
• Knot — thread-per-connection (библиотека Capriccio)
• WatPipe — гибрид (pipeline, аналог SEDA)

Ключевой результат: event-driven µserver и pipeline-based WatPipe обеспечили на ~18% больше пропускной способности, чем thread-based Knot. При этом WatPipe потребовал 25 writer-потоков для достижения той же производительности, что и µserver с 10 процессами.

Pariag D. et al. Comparing the Performance of Web Server Architectures. EuroSys ‘07 (2007). PDF

AEStream: ускорение обработки событий с помощью корутин (2022)

Исследование, опубликованное на arXiv, провело прямое сравнение корутин и потоков для обработки потоковых данных (event-based processing).

Ключевой результат: корутины обеспечили минимум 2x пропускной способности по сравнению с конвенциональными потоками при обработке потока событий.

Pedersen J.E. et al. AEStream: Accelerated Event-Based Processing with Coroutines. (2022). arXiv:2212.10719

5. Масштабируемость: 100 000 задач

Kotlin: 100 000 корутин за 100 ms

В бенчмарке TechYourChance создание и запуск 100 000 корутин заняло ~100 ms overhead. Эквивалентное количество потоков потребовало бы ~1.7 секунды только на создание (100 000 × 17 µs) и ~950 MiB памяти на стеки.

Rust: 250 000 async-задач

В бенчмарке context-switch удалось запустить 250 000 async-задач в одном процессе, в то время как потоки ОС достигли предела на ~80 000.

Go: миллионы goroutines

Go рутинно запускает сотни тысяч и миллионы горутин в production-системах. Именно это позволяет серверам вроде Caddy, Traefik и CockroachDB обрабатывать десятки тысяч одновременных соединений.

6. Сводка доказательной базы

Ссылки

Измерения и бенчмарки

• Eli Bendersky: Measuring context switching for Linux threads (2018)
• Jim Blandy: context-switch benchmark (Rust)
• TechYourChance: Kotlin Coroutines vs Threads Performance
• TechYourChance: Kotlin Coroutines vs Threads Memory
• Super Fast Python: Coroutines Faster Than Threads

Академические работы

• Welsh M. et al. SEDA: An Architecture for Well-Conditioned, Scalable Internet Services. SOSP ‘01. PDF
• Pariag D. et al. Comparing the Performance of Web Server Architectures. EuroSys ‘07. PDF
• Pedersen J.E. et al. AEStream: Accelerated Event-Based Processing with Coroutines. arXiv:2212.10719

Промышленный опыт

• Dan Kegel: The C10K problem (1999)
• Cloudflare: How we scaled nginx
• High Scalability: The Secret to 10 Million Concurrent Connections

См. также

• Python asyncio на практике — production-кейсы (Duolingo, Super.com, Instagram), бенчмарки uvloop, контр-аргументы Cal Paterson
• Swoole на практике — production-кейсы и бенчмарки PHP-корутин