Tornado не сломался — у хорошего выбора просто истёк срок годности

https://www.youtube-nocookie.com/embed/BbyVHtsIM1M

Автор: Дмитрий Ходаков · PyCon Russia 2018

---

В 2015 году команда Авито выбрала Tornado по правильным причинам. Фреймворк был зрелым, выдерживал production-нагрузку и располагал библиотеками для нужных баз данных. На его основе собрали общий шаблон, от которого затем выросли десятки микросервисов.

Через три года сервисы продолжали работать, но изменился сам Python. Нативные async/await и стандартный asyncio сформировали другую модель асинхронного приложения. Tornado тоже развивался, однако за ним тянулись генераторы, глубокие стеки и собственные исторические абстракции. Когда рядом появился aiohttp, прежний разумный выбор начал обходиться дороже нового — хотя формально ничего не сломалось.

Доклад Дмитрия Ходакова полезен в 2026 году именно этой историей. У технологического решения нет вечного преимущества: оно принимается в конкретной экосистеме и может пережить причины, по которым его когда-то выбрали.

Кому смотреть: техническим руководителям и backend-разработчикам, которые поддерживают исправную, но давно выбранную платформу и не понимают, достаточно ли этого для продолжения работы с ней.

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

---

К 2018 году команда рекомендаций Авито эксплуатировала около двадцати Python-микросервисов под нагрузкой порядка 600 RPS. Ответ нужно было вернуть за ограниченное время: показать рекомендации либо вовремя перейти на fallback. Поэтому потерянный где-то внутри библиотеки таймаут был не мелким дефектом, а нарушением важной гарантии всего сервиса.

У Tornado обнаружились именно такие накопленные издержки. При отладке разработчики проходили через многоуровневые внутренние вызовы, а некоторые сетевые библиотеки переставали соблюдать переданный им таймаут. Значительная часть модели фреймворка выросла из генераторов и yield, тогда как новый Python уже предлагал нативные корутины с async/await.

Но команда не стала переписывать сервисы только потому, что новый синтаксис выглядел современнее. Сначала Tornado и aiohttp сравнили под нагрузкой. В простом тесте обработчик ждал 50 мс, Vegeta создавала запросы, а P95 измерялся в пяти запусках по пять минут. На Python 3.6.5 Tornado начинал заметно деградировать после 1100–1200 RPS, тогда как aiohttp сохранял запас при существенно большей нагрузке.

Затем разработчики проверили, откуда взялась разница. Pyflame — ныне заброшенный sampling-профилировщик, подключавшийся к процессу через ptrace, — показал внутреннюю работу обоих фреймворков. При одинаковых 1000 RPS стек Tornado достигал примерно 30 уровней против 15 у aiohttp. Большая доля CPU уходила не на бизнес-логику, а на обслуживание исторических слоёв фреймворка.

В более сложном тесте с множеством конкурентных корутин aiohttp оказался примерно в два с половиной раза производительнее. Сам по себе этот результат ничего не доказывает для современных версий: автор признаёт неточность asyncio.sleep(), различия HTTP-клиентов и ограниченность синтетической нагрузки. Важно другое — benchmark подтвердил подозрение, а profiling объяснил его.

На сцене Ходаков ещё только говорил о вероятном переходе. В опубликованной позднее статье Авито история получила продолжение: команда рекомендаций и некоторые другие команды практически полностью перешли на aiohttp. В их боевых сервисах потребление CPU снизилось более чем вдвое, latency — в два–пять раз, а HTTP-таймауты стали соблюдаться корректно. Это результат конкретной миграции Авито, а не обещание для чужого проекта.

Tornado при этом не исчез. В 2026 году он продолжает поддерживаться и остаётся рабочим фреймворком, особенно для систем с долгоживущими соединениями. Но современный Tornado уже сам опирается на asyncio. Старое противопоставление двух независимых моделей потеряло прежний смысл — и тем лучше видно главное.

Legacy начинается не тогда, когда технология перестаёт работать. Оно начинается тогда, когда команда больше не проверяет, соответствует ли старый выбор новой среде.