Представляю как больно было клиенту когда 1я маджента устарела и вышла вторая с немного «другой» скоростью и сложностью кастомизаций

С другой стороны, потом работал на площадке клиента с рутинными 700К заказов в месяц

на какой платформе если не секрет?

— сессии перетащить в Редис, это — общее место много лет как.

было сделано

— БД — мастер-слейв настроить, вон и в девдокс раздел есть под названием «Split database performance solution»

было сделано

— там же и про Message Queues можно посмотреть — вдруг, что полезное вынесете

мало асинхронного было увы по флоу почти все синхронное было

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

не могу сказать что это прям легко, PHP выполнение при скейлинге лучше, но всеравно в базу упиралось
Есть возможность шардинга базы (на 3 базы разбить) но это привело бы к тому, что потом на мадженто клауд нельзя бы было переехать (что было озвучено клиентом за пол года до черной пятницы)

— ручками профилировать запросы к БД, добавлять (и убирать) индексы, переписывать код в объезд маджентовского БД слоя. Иногда раз в 20-40 производительность поднять удавалось ... ORM там такой, своебразный

более чем валидно, видел на других проектах, работает но не мадженто вей (потом в случае работы с саппортом клауда и траблов с базами саппорт мог бы ссылаться на отпупление от гайдов и best practices (но без плагинов, репозиториев, интерцепторов, обзерверов и тд — 100% быстрее было бы в десятки раз)

— посмотреть на форки MySQL — там тоже что-то выиграть можно

наскольк помню была MariaDB

— девопса взять, чтоб подъем дополнительных нод фронта-бэка автоматизировал нормально, дэшбордов красивых с постоянным анализом логов и алертами нарисовал, NewRelic алерты настроил и т.п.

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

— CloudFlare перед всем поставить можно, иногда полезно.

После проблем с не правильной архитектурой сервера переехали на Fastly, стало лучше

— выделенную команду сапорт-инженеров создать, чтоб накапливали опыт именно эксплкатации подобных систем. Потом можно как отдельный сервис продавать. Задорого.

был доступен сервис 24/7 но шейред между несколькими проектами ( в черную пятницу понятное дело перегруженнее) чем обычно

В целом все пункты точно валидны и чувствуется что были пройдены а не прочитаны )

Это так, что вспомнилось. Я из этого дивного мира Мадженто вышел уже полтора года как, чего и
вам желаю ...

Что дальше? (после мадженты)

Почти так и есть, во второй год я тоже скажал почти то же самое (давайте делить трафик)
(порой сложно написать письмо руководству и описать все что есть а не «соглашаться» на то что хотят и говорить «да» )

Трафик разбили на части и проблем не было вообще
Координация команды была лучше, проанализирвоал ошибки многих получилось избежать

В принципе, кеширование делает в аккурат то же самое.

В Magento 2 чекаут содержит кучу AJAX запросов и не кешируется (остальное — да)

В идеале, если позволяет трафик (вот, кстати, одна из точек компромиса) отдать всё на клиента, сделав поиск по типичным параметрам, а уже когда начнёт клацать галочки — фильтровать у него же на лету. Но поди докажи ещё браузеру не делать оптимистических загрузок

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

Спс за идею

Согласен в чем то, но энтерпрайс боится фриланс (иначе бы аутстаф/аутсор вымер)

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

Огромное спасибо за коммент,
Случилось это год назад и тоже вспоминаю с ностальгией и грустью.

Согласен на 100%! (когда база становится ботлнеком, появляется много проблем, блокировки транзакций, задержки в ответах, цепная реакция на всех типах запросов и быстрого решения в высокий трафик вероятно нет)

Но в целом есть ограничение платформы (Magento 2) даже на их PAS/SAS (Magento Cloud) а точнее Adobe Cloud нет возможности юзать NoSQL

Судя по последним слухам Adobe таки решила переписать все на микросервисы (пусть и с запозданием но вероятно через 1-2 года будет)

Идея хорошая, стыдно (наверное) признать что не слышал ранее о SLO,
спасибо за констуктив и новую абривиатуру для изучения

Буду благодарен если посоветуете интересную книгу / ресурс где это описано достаточно просто и емко

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

мабуть )))

Спасибо, увы DBA не было (был клиентский IT Department без строго описаных ролей) но в целом выделение ролей и их наличие уменьшыло бы вероятность проблем.

MySQL tuner может как помочь, так и поломать

Это да, в целом все что с него получили проверяли и смотрели на динамику работы по к-ву сессий и загрузке DB инстанса, не все помогало сразу)

Спасибо!

Это уже ближе. Дейтсвительно словосочитание «менее громоздкое» лучше передаёт смысл того, что ищу. Спасибо!

symfony.com/projects — интересно что-то по меньше и немного проще. (чем друпал или сам фреймворк допиливать) более ориентированое под задачу.
Спасибо, тема пока актуальна)

+1 прийду ([email protected])