Оптимизация Laravel-приложения | OTUS
🔥 Начинаем BLACK FRIDAY!
Максимальная скидка -25% на всё. Успейте начать обучение по самой выгодной цене.
Выбрать курс

Курсы

Программирование
iOS Developer. Basic
-25%
Python Developer. Professional
-25%
Разработчик на Spring Framework
-25%
Golang Developer. Professional
-25%
Python Developer. Basic
-25%
iOS Developer. Professional
-25%
Highload Architect
-25%
JavaScript Developer. Basic
-25%
Kotlin Backend Developer
-25%
JavaScript Developer. Professional
-25%
Android Developer. Basic
-25%
Unity Game Developer. Basic
-25%
Разработчик C#
-25%
Программист С Web-разработчик на Python Алгоритмы и структуры данных Framework Laravel PostgreSQL Reverse-Engineering. Professional CI/CD Vue.js разработчик VOIP инженер Программист 1С Flutter Mobile Developer Супер - интенсив по Kubernetes Symfony Framework Advanced Fullstack JavaScript developer Супер-интенсив "Azure для разработчиков"
Инфраструктура
Мониторинг и логирование: Zabbix, Prometheus, ELK
-25%
DevOps практики и инструменты
-25%
Архитектор сетей
-25%
Инфраструктурная платформа на основе Kubernetes
-25%
Супер-интенсив «ELK»
-16%
Супер-интенсив «IaC Ansible»
-16%
Супер-интенсив "SQL для анализа данных"
-16%
Базы данных Сетевой инженер AWS для разработчиков Cloud Solution Architecture Разработчик голосовых ассистентов и чат-ботов Внедрение и работа в DevSecOps Администратор Linux. Виртуализация и кластеризация Нереляционные базы данных Супер-практикум по использованию и настройке GIT IoT-разработчик Супер-интенсив «СУБД в высоконагруженных системах»
Специализации Курсы в разработке Подготовительные курсы
+7 499 938-92-02

Оптимизация Laravel-приложения

Laravel_Deep_2.4-5020-6f82e4.png

Хочу поделиться небольшим кейсом оптимизации Laravel-приложения. Этот кейс служит хорошей иллюстрацией алгоритма оптимизации в целом, в процессе пришлось столкнуться с типичными проблемами, плюс он содержит несколько решений, относящихся именно к Laravel.

Исходно имеем микросервис авторизации, владеющий информацией о правах пользователей, реализованный на Laravel. Правами пользователи наделяются через роли (RBAC), система прав выглядит следующим образом: — трёхуровневое дерево; — на верхнем уровне — сервисы; — посередине — страницы; — на нижнем уровне — элементы страниц.

Для страниц и элементов страниц есть набор действий, которые с ними можно осуществлять. В тот момент времени, когда было решено заняться оптимизацией, сервис тратил на ответ о правах пользователя в рамках сервиса ~140 мс, что позволяло выдерживать только стандартную нагрузку и совсем не позволяло пиковую. Для удержания пиковой нагрузки без апгрейда сервера необходимо было снизить время ответа хотя бы до 50 мс. Целевым показателем было выбрано 20 мс, чтобы иметь запас по производительности.

Выполненные шаги по оптимизации

  1. Анализ запросов к БД (отказ от Eloquent и доменной модели прав). Поскольку данные о правах представлены иерархической структурой, но хранятся в реляционной БД (PostgreSQL), то первое предположение было о том, что основные «тормоза» происходят на этапе работы с БД. Анализ показал, что Eloquent выполнял O(N) запросов, где N – количество сервисов. Для получения набора прав было решено отказаться от Eloquent и доменной модели прав. Запросы переписаны на «сырой» SQL, в результате их количество сокращено до 3 (по одному для каждого уровня), плюс проводится дополнительная обработка результатов в коде. В результате время подготовки ответа удалось сократить до ~100 мс.
  2. Денормализация данных. Принято решение денормализовать данные и хранить в БД уже подготовленный ответ с полным набором прав пользователя по всем сервисам уже в JSON-формате, что позволит не тратить время на обработку и сократит время выборки. Как результат, удалось сократить ещё 2 запроса к БД и время подготовки ответа стало ~70 мс.
  3. Проблема обновления данных. После денормализации было установлено, что существует юзеркейс, в котором пользователям несколько раз меняется набор прав, после чего они тут же запрашиваются. Денормализация привела к тому, что время обновления прав существенно возросло, и в этом кейсе время подготовки ответа пользователю вернулось почти к исходному показателю (стало ~130 мс). Кейс не был очень существенным, однако подвёл к мысли, что решение пока неоптимально. В качестве дополнительной оптимизации изменили алгоритм денормализации и стали хранить данные по правам на каждый сервис в отдельном поле и отдавать информацию о правах на каждый сервис по отдельности (бизнес-логику это не нарушило, т. к. каждому сервису интересны права только про его страницы и элементы). Это позволило обновлять данные частично и немного уменьшило трафик, в итоге время подготовки типичного ответа стало ~60 мс, а в рассмотренном юзеркейсе ~90 мс.
  4. Выносим данные в кэш. Денормализованные данные стало возможно вынести в кэш, т. к. теперь обновление прав затрагивало конкретные кэшированные данные, которые можно было легко инвалидировать. Это позволило сократить время подготовки типичного ответа до ~50 мс. Пиковую нагрузку уже стало можно выдерживать, но без какого-либо запаса прочности.
  5. Оптимизируем работу IoC-контейнера (отказ от автоматического DI). Дальнейшая оптимизация со стороны источников данных уже не могла дать значительного прироста производительности, поэтому начали оптимизировать уже работу кода. В процессе анализа выяснилось, что автоматический подбор классов, реализующих требуемые интерфейсы в IoC-контейнере, достаточно медленный. Было решено отказаться от этого механизма и подсказывать контейнеру явно конкретные классы без привязки к интерфейсам. Это позволило сократить время до ~45 мс.
  6. Делаем часть работы IoC-контейнера вручную. Следующим шагом стал полный отказ от использования контейнера для инстанцирования отдельных сущностей, которые использовались для подготовки ответа с набором прав пользователя. Т. е. в провайдере служб эти сущности собирались вручную с lazy-инициализацией. Смогли выиграть ещё немного и получили результат ~37 мс.
  7. Оптимизация роутинга. Сервис поддерживал порядка 60 различных запросов, что приводило к довольно медленному роутингу. Часть запросов была удалена (в них возвращалась частично информация о правах, теперь стал использоваться полный вариант), часть объединена с переходом на дополнительные параметры в теле запроса. В результате удалось сократить количество запросов до ~20. Эта оптимизация плюс включение кэширования в провайдере роутинга позволило сократить время до ~30 мс (включение кэширования без оптимизации давало результат ~33 мс).

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

Не пропустите новые полезные статьи!

Спасибо за подписку!

Мы отправили вам письмо для подтверждения вашего email.
С уважением, OTUS!

Автор
0 комментариев
Для комментирования необходимо авторизоваться
🎁 Максимальная скидка!
Черная пятница уже в OTUS! Скидка -25% на всё!