🚀 Как Duolingo ускорил микросервисы на 40% с помощью асинхронного Python 🐍⚡
Duolingo рассказали, как им удалось значительно повысить производительность своих Python-сервисов, переведя их на
💸 Мотивация: производительность и снижение затрат
Duolingo работает с большим количеством микросервисов, обрабатывающих огромные объёмы трафика. Несмотря на высокую нагрузку, многие их Python-сервисы простаивали в ожидании I/O — например, сетевых запросов или операций с базой данных. Это означало неэффективное использование CPU, а значит — деньги на облачный хостинг тратились зря.
Асинхронный код — способ “переключаться” между задачами во время ожидания, используя CPU с большей отдачей. Именно это стало главной мотивацией: не “просто быть async”, а снизить расходы.
⚙️ Как проходила миграция
Процесс был постепенным и продуманным. Ниже ключевые шаги:
▪ Переход не “всё или ничего”
Команда не бросалась переписывать весь сервис с нуля. Они начали с конвертации отдельных маршрутов (routes) на async def, добавляя поддержку асинхронности по частям.
▪ Инструменты постепенно адаптировали
Библиотеки и инструменты внутри компании пришлось обновить:
▪ свой HTTP-клиент переписали под aiohttp,
▪ систему аутентификации сделали совместимой с async-контекстами,
▪ логирование, трассировка и метрики обновили под async-архитектуру.
▪ Тесты и инфраструктура
Асинхронные изменения требовали пересмотра тестов. Они внедрили поддержку pytest-asyncio и переосмыслили подход к мокам и фикстурам.
▪ Запуск в проде — поэтапно
Сначала маршруты работали в синхронном режиме. Потом их перевели в async-режим и замерили разницу. Так удалось отловить “узкие места” до массового внедрения.
📈 Результаты: +40% производительности на инстанс
▪ У каждого экземпляра микросервиса CPU начал использоваться эффективнее.
▪ Снизилось среднее время ответа (latency).
▪ Уменьшилось количество необходимых инстансов — экономия в $$$.
▪ Код стал удобнее масштабировать и поддерживать в I/O-интенсивной среде.
Пока один запрос “ждёт”, процессор может выполнять другие задачи.
🔍 Выводы
Duolingo подчёркивает:
асинхронность не нужна “просто потому что модно”.
Но если у вас сервис с большим числом I/O-операций и важна производительность — async Python может дать реальный прирост и экономию.
➡ Оригинальный пост
@pythonl
Duolingo рассказали, как им удалось значительно повысить производительность своих Python-сервисов, переведя их на
async/await, и сделали это не ради хайпа, а ради экономии.💸 Мотивация: производительность и снижение затрат
Duolingo работает с большим количеством микросервисов, обрабатывающих огромные объёмы трафика. Несмотря на высокую нагрузку, многие их Python-сервисы простаивали в ожидании I/O — например, сетевых запросов или операций с базой данных. Это означало неэффективное использование CPU, а значит — деньги на облачный хостинг тратились зря.
Асинхронный код — способ “переключаться” между задачами во время ожидания, используя CPU с большей отдачей. Именно это стало главной мотивацией: не “просто быть async”, а снизить расходы.
⚙️ Как проходила миграция
Процесс был постепенным и продуманным. Ниже ключевые шаги:
▪ Переход не “всё или ничего”
Команда не бросалась переписывать весь сервис с нуля. Они начали с конвертации отдельных маршрутов (routes) на async def, добавляя поддержку асинхронности по частям.
▪ Инструменты постепенно адаптировали
Библиотеки и инструменты внутри компании пришлось обновить:
▪ свой HTTP-клиент переписали под aiohttp,
▪ систему аутентификации сделали совместимой с async-контекстами,
▪ логирование, трассировка и метрики обновили под async-архитектуру.
▪ Тесты и инфраструктура
Асинхронные изменения требовали пересмотра тестов. Они внедрили поддержку pytest-asyncio и переосмыслили подход к мокам и фикстурам.
▪ Запуск в проде — поэтапно
Сначала маршруты работали в синхронном режиме. Потом их перевели в async-режим и замерили разницу. Так удалось отловить “узкие места” до массового внедрения.
📈 Результаты: +40% производительности на инстанс
▪ У каждого экземпляра микросервиса CPU начал использоваться эффективнее.
▪ Снизилось среднее время ответа (latency).
▪ Уменьшилось количество необходимых инстансов — экономия в $$$.
▪ Код стал удобнее масштабировать и поддерживать в I/O-интенсивной среде.
Пока один запрос “ждёт”, процессор может выполнять другие задачи.
🔍 Выводы
Duolingo подчёркивает:
асинхронность не нужна “просто потому что модно”.
Но если у вас сервис с большим числом I/O-операций и важна производительность — async Python может дать реальный прирост и экономию.
➡ Оригинальный пост
@pythonl
tgoop.com/pythonl/4731
Create:
Last Update:
Last Update:
🚀 Как Duolingo ускорил микросервисы на 40% с помощью асинхронного Python 🐍⚡
Duolingo рассказали, как им удалось значительно повысить производительность своих Python-сервисов, переведя их на
💸 Мотивация: производительность и снижение затрат
Duolingo работает с большим количеством микросервисов, обрабатывающих огромные объёмы трафика. Несмотря на высокую нагрузку, многие их Python-сервисы простаивали в ожидании I/O — например, сетевых запросов или операций с базой данных. Это означало неэффективное использование CPU, а значит — деньги на облачный хостинг тратились зря.
Асинхронный код — способ “переключаться” между задачами во время ожидания, используя CPU с большей отдачей. Именно это стало главной мотивацией: не “просто быть async”, а снизить расходы.
⚙️ Как проходила миграция
Процесс был постепенным и продуманным. Ниже ключевые шаги:
▪ Переход не “всё или ничего”
Команда не бросалась переписывать весь сервис с нуля. Они начали с конвертации отдельных маршрутов (routes) на async def, добавляя поддержку асинхронности по частям.
▪ Инструменты постепенно адаптировали
Библиотеки и инструменты внутри компании пришлось обновить:
▪ свой HTTP-клиент переписали под aiohttp,
▪ систему аутентификации сделали совместимой с async-контекстами,
▪ логирование, трассировка и метрики обновили под async-архитектуру.
▪ Тесты и инфраструктура
Асинхронные изменения требовали пересмотра тестов. Они внедрили поддержку pytest-asyncio и переосмыслили подход к мокам и фикстурам.
▪ Запуск в проде — поэтапно
Сначала маршруты работали в синхронном режиме. Потом их перевели в async-режим и замерили разницу. Так удалось отловить “узкие места” до массового внедрения.
📈 Результаты: +40% производительности на инстанс
▪ У каждого экземпляра микросервиса CPU начал использоваться эффективнее.
▪ Снизилось среднее время ответа (latency).
▪ Уменьшилось количество необходимых инстансов — экономия в $$$.
▪ Код стал удобнее масштабировать и поддерживать в I/O-интенсивной среде.
Пока один запрос “ждёт”, процессор может выполнять другие задачи.
🔍 Выводы
Duolingo подчёркивает:
асинхронность не нужна “просто потому что модно”.
Но если у вас сервис с большим числом I/O-операций и важна производительность — async Python может дать реальный прирост и экономию.
➡ Оригинальный пост
@pythonl
Duolingo рассказали, как им удалось значительно повысить производительность своих Python-сервисов, переведя их на
async/await, и сделали это не ради хайпа, а ради экономии.💸 Мотивация: производительность и снижение затрат
Duolingo работает с большим количеством микросервисов, обрабатывающих огромные объёмы трафика. Несмотря на высокую нагрузку, многие их Python-сервисы простаивали в ожидании I/O — например, сетевых запросов или операций с базой данных. Это означало неэффективное использование CPU, а значит — деньги на облачный хостинг тратились зря.
Асинхронный код — способ “переключаться” между задачами во время ожидания, используя CPU с большей отдачей. Именно это стало главной мотивацией: не “просто быть async”, а снизить расходы.
⚙️ Как проходила миграция
Процесс был постепенным и продуманным. Ниже ключевые шаги:
▪ Переход не “всё или ничего”
Команда не бросалась переписывать весь сервис с нуля. Они начали с конвертации отдельных маршрутов (routes) на async def, добавляя поддержку асинхронности по частям.
▪ Инструменты постепенно адаптировали
Библиотеки и инструменты внутри компании пришлось обновить:
▪ свой HTTP-клиент переписали под aiohttp,
▪ систему аутентификации сделали совместимой с async-контекстами,
▪ логирование, трассировка и метрики обновили под async-архитектуру.
▪ Тесты и инфраструктура
Асинхронные изменения требовали пересмотра тестов. Они внедрили поддержку pytest-asyncio и переосмыслили подход к мокам и фикстурам.
▪ Запуск в проде — поэтапно
Сначала маршруты работали в синхронном режиме. Потом их перевели в async-режим и замерили разницу. Так удалось отловить “узкие места” до массового внедрения.
📈 Результаты: +40% производительности на инстанс
▪ У каждого экземпляра микросервиса CPU начал использоваться эффективнее.
▪ Снизилось среднее время ответа (latency).
▪ Уменьшилось количество необходимых инстансов — экономия в $$$.
▪ Код стал удобнее масштабировать и поддерживать в I/O-интенсивной среде.
Пока один запрос “ждёт”, процессор может выполнять другие задачи.
🔍 Выводы
Duolingo подчёркивает:
асинхронность не нужна “просто потому что модно”.
Но если у вас сервис с большим числом I/O-операций и важна производительность — async Python может дать реальный прирост и экономию.
➡ Оригинальный пост
@pythonl
BY Python/ django
Share with your friend now:
tgoop.com/pythonl/4731