Хвост инженера

Автор: Ильяс Салихов · PHP Russia 2022

ORM умеет сгенерировать миграцию, но не знает, выдержит ли её production. На таблице в сто миллионов строк обычный UPDATE, добавление ограничения или перестройка связей могут надолго занять базу блокировками. Формально схема обновляется правильно — а приложение в это время отвечает ошибками.

Ильяс Салихов показывает, как RetailCRM работает с PostgreSQL при постоянной нагрузке около 100 тысяч транзакций в секунду. Самая полезная часть доклада — не отдельные настройки PostgreSQL, а отношение к изменению схемы как к серии совместимых релизов. Новая структура сначала появляется рядом со старой, приложение некоторое время пишет в обе, данные переносятся порциями, чтение переключается отдельно — и только после проверки удаляется прежняя модель.

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

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

Автор: Антон Титов (SpiralScout) · PHP Russia 2019

Классическая модель PHP начинает каждый запрос почти с чистого состояния: загружает приложение, создаёт контейнер и после отправки ответа освобождает процесс. RoadRunner сохраняет PHP worker между запросами — и тем самым превращает прежнюю гарантию очистки в ответственность разработчика.

Антон Титов показывает гибридную архитектуру, в которой сервер на Go принимает запросы и управляет долгоживущими PHP-процессами. Приложение не нужно загружать заново для каждого обращения, поэтому уменьшается стоимость инициализации. На уровне HTTP автор заявляет ускорение примерно в двадцать раз, хотя такой результат относится к конкретному benchmark, а не к любому PHP-проекту.

У производительности есть обратная сторона. Объект, соединение или пользовательский контекст теперь способны пережить запрос, для которого были созданы. PHP-приложение должно работать как настоящий долгоживущий сервис, а не рассчитывать, что процесс автоматически уничтожит всё состояние.

Кому смотреть: PHP-разработчикам, которые рассматривают RoadRunner, FrankenPHP или другую модель долгоживущих workers.

Из этого можно взять в работу: проверить сервисы и singleton-объекты приложения на данные текущего пользователя, запроса или транзакции, которые могут остаться в памяти после ответа.

Автор: Николай Павлин · «Павлин Шарит — ИТ вместе с Николаем Павлиным»

Поле status отвечает на вопрос, в каком состоянии находится заказ сейчас. Оно не объясняет, какие состояния были допустимы раньше, куда заказ может перейти дальше и что должно произойти при переходе.

Николай Павлин показывает, как вынести эти правила в конечный автомат с помощью Python-библиотеки python-statemachine. Состояния и переходы объявляются отдельно, недопустимые изменения блокируются библиотекой, а действия и условия можно привязать к конкретным переходам жизненного цикла.

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

Кому смотреть: Python-разработчикам, у которых правила изменения статуса сущности начали повторяться в разных частях приложения.

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

Автор: Ильяс Салихов (retailCRM) · PHP Russia 2019

Язык с быстрым runtime не обязательно делает разработку сервиса дешевле. Если приложению нужны сотни полей, сложная валидация, связи между сущностями и миграции, стоимость готовых прикладных абстракций может оказаться важнее производительности самого языка.

Ильяс Салихов сравнивает PHP и Go на опыте retailCRM. На момент доклада систему обслуживали около тридцати сервисов: примерно 60% были написаны на PHP с Symfony, 30% — на Go. Автор не выбирает победителя, а показывает задачи, для которых в компании использовали каждый стек.

PHP выигрывал в насыщенных бизнес-приложениях. Symfony и Doctrine давали ORM, Unit of Work, миграции, формы и валидацию. Go выбирали для небольших API и сервисов с конкурентной обработкой, где были полезны goroutines, производительность и поставка одним бинарником.

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

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

Автор: Даниил Коноваленко (Яндекс Go) · Python Channel · Moscow Python Conf++ 2021

Даниил Коноваленко — backend-разработчик в Яндекс Go. В подразделении несколько сотен микросервисов, треть из них написана на Python. Однажды во время дежурства пришёл алерт: один из сервисов занял 91% памяти. Открыв графики — всё выглядело нормально. Открыв на большем масштабе — характерный паттерн: память растёт линейно и никогда не возвращается. После перезапуска — то же самое. Это и есть утечка.

Доклад — детективная история с реальным production-кейсом. Три акта: как утечка выглядит и как её опознать, откуда они берутся в языке с GC, какие инструменты помогают найти и исправить.

Кому смотреть: backend-разработчикам на Python, которые деплоят сервисы в production и уверены что GC за них всё уберёт. После этого доклада — чуть менее уверены, зато знают что делать.

Из этого можно взять в работу: если у вашего сервиса есть метрика потребления памяти — посмотрите на неё на масштабе нескольких дней. Линейный рост без возврата после GC-цикла — сигнал для расследования, а не повод «накинуть памяти и посмотреть».

Автор: Артём Малышев · Moscow Python Conf 2016

⚠️ Материал 2016 года, Django Channels 1.x. Концептуальный разбор «зачем это нужно» остаётся актуальным. Детали API и конкретные паттерны с тех пор существенно изменились (Channels 2.x переписал архитектуру Channel Layer). Сверяйтесь с актуальной документацией.

Классический Django построен на WSGI — стандарте, появившемся в 2003 году. Его базовый контракт прост: принять запрос, вернуть ответ. Никакой асинхронности, никаких долгоживущих соединений. Это сознательный дизайн для эпохи, когда веб состоял из страниц с новостями и гостевых книг.

Современный веб хочет другого: живой контент без перезагрузки страницы, WebSocket-соединения, уведомления в реальном времени — пользователи не хотят нажимать F5. Django Channels — это ответ на этот запрос: расширение, добавляющее поддержку асинхронных протоколов поверх синхронного фреймворка.

Кому смотреть: Django-разработчикам, которым нужны WebSocket или long-polling, и которые хотят понять как Channels вписывается в Django-архитектуру — особенно где заканчивается синхронный Django и начинается async.

Из этого можно взять в работу: если добавляете real-time функциональность в Django-проект — поймите границу между синхронным Django (models, ORM, middleware) и async Channel Layer до того как начнёте писать код. Смешивать их без понимания этой границы — источник трудноуловимых проблем.

Автор: Александр Морозов (co-founder & CTO, Datafold) · Python Channel · Moscow Python Conf++ 2021

Datafold — стартап из YCombinator, платформа мониторинга аналитических данных. Прошли акселератор, писали MVP за 1–2 месяца — за основу взяли Redash (MIT-лицензия, аналитические БД, SPA). Redash целиком построен на Flask: sqlalchemy, alembic, REST, auth, rate-limiters, CSRF, CLI. Через какое-то время решили менять стек.

Название доклада начинается с «Не highload» — и это принципиально. Причина переезда не в том, что Flask медленный. Причина в том, что типичный Flask-хэндлер — это огромный boilerplate для простых вещей: получить данные из тела запроса как JSON, провалидировать, сконвертировать. Хочешь нормальные сообщения об ошибках — boilerplate вырастает ещё в несколько раз. FastAPI решает это через type hints и Pydantic: код становится короче, читаемее и самодокументируемым.

Кому смотреть: разработчикам на Flask, которые думают о переходе на FastAPI — или уже переходят. Морозов рассказывает не то, что написано в документации, а конкретные проблемы при реальном переезде и как их обошли.

Из этого можно взять в работу: если у вас Flask и вы тратите значительное время на boilerplate для валидации запросов — это именно тот сигнал. FastAPI с Pydantic закрывает эту боль, а не задачу throughput.

Автор: Владимир Протасов · Habr

Владимир Протасов — разработчик с опытом highload-систем, выступал на HighLoad++ 2016 с докладом об OpenResty. Доклад из тех, что не устаревают: OpenResty существует с 2009 года, но основная масса разработчиков по-прежнему думает о нём как о «Nginx с Lua» и недооценивает, что именно это означает.

OpenResty встраивает LuaJIT прямо в worker-процессы Nginx и даёт хуки на каждую фазу обработки запроса: до получения заголовков, после, перед отправкой ответа, при ошибке. Это не «скрипт, вызываемый Nginx» — это Lua, исполняемый с той же производительностью, что и сам Nginx, без форков, без HTTP-запросов к отдельному backend, без копирования тела запроса туда-обратно. Авторизация, rate limiting, трансформация ответов, маршрутизация на основе тела запроса — всё это можно делать без выхода из nginx-контекста.

Протасов разбирает конкретные паттерны: как подключить Redis через cosocket API (без блокировки event loop), как кешировать сессии, как писать обработчики для нестандартных протоколов. Это не «hello world на Lua в nginx», а production-архитектура.

Кому смотреть: backend-разработчикам, которые используют Nginx как reverse proxy и хотят перенести часть логики (auth, rate limiting, A/B-роутинг) ближе к трафику, не добавляя отдельный сервис.

Из этого можно взять в работу: если у тебя есть endpoint, который только проверяет token и проксирует запрос дальше — попробуй вынести проверку на уровень OpenResty. Latency упадёт, а отдельный auth-сервис в цепочке исчезнет.

Автор: Артём Шумейко · YouTube

Артём Шумейко — Python-разработчик и преподаватель, специализируется на backend. В коротком видео показывает на живом примере и с реальными цифрами, как FastAPI обрабатывает больше тысячи запросов в секунду.

Асинхронность часто объясняют через «это быстро» — и это неточная формулировка, которая потом мешает. FastAPI не делает CPU-код быстрее. Он устраняет простой: пока один запрос ждёт ответа от базы данных или внешнего сервиса, event loop берёт следующий. При I/O-bound нагрузке это даёт кратный прирост пропускной способности без дополнительных потоков и без накладных расходов на переключение контекста. Видео полезно тем, что показывает разницу измеримо, а не концептуально.

Кому смотреть: Python-разработчикам, которые пишут async/await по инерции или «потому что так принято в FastAPI», но не могут объяснить, почему это работает и когда это не поможет.

Из этого можно взять в работу: найди в своём коде async-функцию, которая делает блокирующий вызов — requests.get() вместо httpx, time.sleep() вместо asyncio.sleep(). Одна такая точка блокирует весь event loop.