Обновить

Как мы перестраивали e‑commerce‑платформу в production: от legacy‑системы к Next.js и Symfony

Уровень сложностиСредний
Время на прочтение18 мин
Охват и читатели6.3K
Всего голосов 3: ↑3 и ↓0+6
Комментарии4

Комментарии 4

Было интересно почитать, спасибо за статью.

Symfony отвечает за серверную бизнес‑логику, данные и административную часть

Как говорится, спасибо, что не Magento. Рассматривали ли более быстрые решения вместо Symfony, например, Slim 4? Был опыт со всеми тремя в очень больших международных проектах, имхо Slim 4 лучший по скорости. Да, он гол как сокол, но полная поддержка нужных PSR позволяет лепить CRUD-ы админки, бизнес-логику и интеграции не приходя в сознание.

Для нас при выборе была важна не только скорость самого фреймворка, но и то, что backend должен был стать основой довольно большой системы: API, административной части, бизнес-логики, интеграций и работы с большим каталогом.

В процессе эксплуатации основные проблемы с производительностью у нас чаще оказывались не на уровне Symfony как такового, а в запросах к БД, объёме обрабатываемых данных, интеграциях и кэшировании. Поэтому переход на более лёгкий фреймворк сам по себе вряд ли дал бы тот эффект, который можно получить оптимизацией этих участков.

Но Slim 4 для более компактного сервиса или отдельного API действительно интересный вариант. Любопытно, на каких объёмах у вас разница между Symfony и Slim становилась уже заметной именно в production?

Любопытно, на каких объёмах у вас разница между Symfony и Slim становилась уже заметной именно в production?

Сотни одновременных пользователей в чекауте на распродажах, особенно на black fridаy и cyber monday. Выглядит как цунами на графиках мониторинга.

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

В итоге по скорости и памяти в реальной нагрузке выигрышь был в 2.8 раза, при расчетной в 4 раза.

Также большая нагрузка бывала от варехаусов (отделения по всему миру), но конечно не такая как на распродажах.

Из минусов, много чего из того, что есть в Symfony из коробки, пршлось писать руками.

Да, тогда понятно, почему разница получилась настолько заметной. Каталог в таком случае действительно в основном закрывается кэшем, а checkout с большим объёмом бизнес-логики уже показывает разницу непосредственно между приложениями. 2,8 раза на реальной нагрузке — очень существенный результат.

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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации