Как мы ускорили Laravel API в пять раз

С чего начать оптимизацию

Оптимизацию всегда стоит начинать с измерений, а не с догадок. Прежде чем менять код, мы сняли профиль реальных запросов и нашли, что 80% времени отклика уходит на обращения к базе данных, а не на бизнес-логику. Поэтому первой целью стала именно работа с данными.

Боремся с проблемой N+1

Самой частой причиной медленных эндпоинтов оказалась проблема N+1: для списка из ста сущностей выполнялось больше сотни дополнительных запросов к связям. Жадная загрузка через with() сократила это до нескольких запросов.

Что именно мы изменили

• Добавили eager loading для всех связей, используемых в ресурсах ответа.
• Включили защиту от ленивой загрузки в окружении разработки, чтобы ловить N+1 на ранних этапах.
• Вынесли тяжёлые агрегаты в отдельные оптимизированные запросы.

Кэшируем горячие данные

Редко меняющиеся справочники и тяжёлые выборки мы вынесли в Redis с продуманной инвалидацией по событиям. Это сняло значительную часть нагрузки с PostgreSQL и стабилизировало латентность под пиковым трафиком.

Резидентный режим

Финальным шагом стал запуск приложения в резидентном режиме, что убрало накладные расходы на холодную инициализацию фреймворка на каждый запрос. В сумме все меры дали пятикратное ускорение среднего времени отклика.

Итоги

Системный подход — измерить, найти узкое место, исправить и снова измерить — позволил добиться кратного ускорения без переписывания приложения. Главный урок: оптимизируйте по данным профилирования, а не по интуиции.