Да, тогда понятно, почему разница получилась настолько заметной. Каталог в таком случае действительно в основном закрывается кэшем, а checkout с большим объёмом бизнес-логики уже показывает разницу непосредственно между приложениями. 2,8 раза на реальной нагрузке — очень существенный результат.
Ну и обратная сторона Slim как раз понятна — выигрыш в лёгкости приходится оплачивать тем, что часть того, что Symfony даёт из коробки, нужно собирать самостоятельно. Спасибо, интересный практический кейс.
Для нас при выборе была важна не только скорость самого фреймворка, но и то, что backend должен был стать основой довольно большой системы: API, административной части, бизнес-логики, интеграций и работы с большим каталогом.
В процессе эксплуатации основные проблемы с производительностью у нас чаще оказывались не на уровне Symfony как такового, а в запросах к БД, объёме обрабатываемых данных, интеграциях и кэшировании. Поэтому переход на более лёгкий фреймворк сам по себе вряд ли дал бы тот эффект, который можно получить оптимизацией этих участков.
Но Slim 4 для более компактного сервиса или отдельного API действительно интересный вариант. Любопытно, на каких объёмах у вас разница между Symfony и Slim становилась уже заметной именно в production?
Information
Rating
1,697-th
Registered
Activity
Specialization
Архитектор программного обеспечения, Руководитель разработки и архитектуры ПО
Да, тогда понятно, почему разница получилась настолько заметной. Каталог в таком случае действительно в основном закрывается кэшем, а checkout с большим объёмом бизнес-логики уже показывает разницу непосредственно между приложениями. 2,8 раза на реальной нагрузке — очень существенный результат.
Ну и обратная сторона Slim как раз понятна — выигрыш в лёгкости приходится оплачивать тем, что часть того, что Symfony даёт из коробки, нужно собирать самостоятельно. Спасибо, интересный практический кейс.
Для нас при выборе была важна не только скорость самого фреймворка, но и то, что backend должен был стать основой довольно большой системы: API, административной части, бизнес-логики, интеграций и работы с большим каталогом.
В процессе эксплуатации основные проблемы с производительностью у нас чаще оказывались не на уровне Symfony как такового, а в запросах к БД, объёме обрабатываемых данных, интеграциях и кэшировании. Поэтому переход на более лёгкий фреймворк сам по себе вряд ли дал бы тот эффект, который можно получить оптимизацией этих участков.
Но Slim 4 для более компактного сервиса или отдельного API действительно интересный вариант. Любопытно, на каких объёмах у вас разница между Symfony и Slim становилась уже заметной именно в production?