<b>Octane ускоряет Laravel, но ломает привычки: что проверить до запуска в прод</b>

<b>Octane ускоряет Laravel, но ломает привычки: что проверить до запуска в прод</b>

Octane убирает часть накладных расходов фреймворка, но вместе с этим меняет модель жизни приложения. Если код писал как для обычного PHP-FPM, всплывают странные баги: «залипшие» данные между запросами, неожиданные singleton-состояния, утечки памяти.

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

Второе — проверить всё, что использует глобальное состояние: auth context, locale, request data, time zone, headers. В Octane это нужно явно сбрасывать или пересоздавать, иначе один запрос начинает влиять на следующий.

Третье — внимательно смотреть на внешние клиенты и соединения. HTTP-клиенты, очереди, кеш, базы, файловые адаптеры: если библиотека не рассчитана на long-running process, она быстро проявит себя не там, где нужно.

И ещё один момент: профилируй память не только под нагрузкой, но и на серии обычных запросов. Octane часто ускоряет «счастливый путь», а проблемы видны только после десятков одинаковых обращений подряд.

Если запускаешь Octane, сначала пройдись по коду как по состоянию в памяти, а не как по набору статeless-роутов. Это экономит больше времени, чем любая оптимизация на уровне middleware.