Випуск продуктивності з 1k до 10k веб-сайтів / магазинів

Я намагаюся знайти спосіб покращити продуктивність Magento, коли кількість веб-сайтів / магазинів перевищує 1 к, а моя мета - близько 10 к. Ось кілька питань; будь-які поради / допомога надзвичайно вітаються!

1. Додавання нових веб-сайтів / магазинів відбувається повільно;
   Я коментую $ this-> cleanModelCache () в _afterSave () в Mage_Core_Model_Ab Абстракція, і ситуація здається кращою, але стає все повільніше із збільшенням кількості веб-сайтів / магазинів. І я не знаю, що це вплине на всю систему в майбутньому.

2. Api-дзвінки стають повільними.
   Один з основних процесів - це наведення порядку; моя спеціалізована модель займається цим обробкою деяких даних і фактично використовуючи модель продажу / котирування та моделі продажу / послуги_ цитата. Процес починається з Оаута. І Oauth, і замовлення займають більше часу, коли кількість веб-сайтів / магазинів зростає, а споживання пам'яті здається більшим. Чи пов’язано це з тим, що Mage завантажує config xml, і тим, що дані конфігурації збільшуються зі збільшенням кількості веб-сайтів?

3. Відкриття n98-magerun dev: консоль займає більше часу; не знаю причини цього.

4. Збереження конфігурації з панелі адміністратора займає більше часу; не знаю, як її покращити.

Чи можливо реконструювати спосіб Magento генерувати та завантажувати конфігураційні дані, щоб знизити споживання пам'яті? Це один із факторів, які спричиняють проблеми в моїй ситуації?

Поточний екземпляр Magento: Версія = Magento EE 1.14.2.4;
Налаштувати кеш; інший кеш вимкнено;
Використання Mysql 5.6 та MongoDB (для каталогу_category_entity, catalog_product_entity, core_website);
кількість веб-сайтів = кількість магазинів = кількість переглядів = 1024;
кількість товару = 4501;

Дякую всім заздалегідь!

Однією з причин того, що він стає повільним, є те, що конфігурація кожного магазину дублюється з / config / веб-сайтів та / config / global, а код для цього не менш ефективний. Будь-яка зміна налаштувань може призвести до зниження 10-хвилин, якщо не годин, зниження продуктивності та пропускної здатності. Зробити це більш ефективним, в основному буде означати, що Бен Маркс піде за вами ... і не в хороший спосіб.

Якщо ви збираєтеся спуститися цим маршрутом, найпростішим способом було б мати встановлення 10k Magento та мати якогось брокера, який делегує запити на відповідний веб-сайт. Хоча, звичайно, це залежатиме від конкретного випадку використання.

[додано]

Залежно від випадку використання ви можете використовувати категорії як псевдо магазини. Технічно ви можете використовувати макет XML, щоб змінити тематику в магазині. Але тоді ви зіткнетеся з обмеженням оформлення каси. Усі магазини повинні поділити замовлення.

Так чи інакше, магазини Magento 10k можна зробити, оскільки це неможливо. Але це буде непроста дорога, який би шлях ви не вибрали.

Ви можете спробувати зламати ядро ​​та ввімкнути розбиття кешу веб-сайту. Ви можете спробувати зламати базу даних та зберігати інформацію про конфігурацію в пам'яті. Ви можете спробувати замінити кеш конфігурації чимось розумнішим - скажімо кешування інформації з файлів xml [які є статичними та застосовуються до всіх веб-сайтів та магазинів], одночасно динамічно витягуючи дані заміщення.

Я серверний хлопець, тож я хотів би спілкуватися з базою даних. Тим більше, що це банально робити.

Якщо у вас є контроль над сервером бази даних: Перейменуйте таблицю core_config_data в core_config_data_offline Створіть нову таблицю core_config_data за допомогою механізму зберігання даних MEMORY http://dev.mysql.com/doc/refman/5.7/en/memory-storage-engine.html Скопіюйте всі дані з core_config_data_offline в core_config_data

Налаштуйте завдання cron, щоб перевірити, чи є core_config_data, чи він копіює всі дані звідти в core_config_data_offline. Якщо цього немає, створіть його та скопіюйте все від core_config_data_offline до core_config_data

Вимкніть кеш-конфігурацію. Якщо кеш конфігурації увімкнено, ви отримуєте лише підвищення продуктивності вперше, коли дані конфігурації читаються з бази даних - після цього вони знаходяться в кеші, і ви страждаєте. Знизу файли xml більше не кешовані, тому ви торгували хітом продуктивності несеріалізації величезних даних конфігурації для хіт-характеристики для аналізу синтаксису файлів xml.

Ви також можете поекспериментувати зі зміною файла Mage / Core / Model / Config.php та включити окремі кеші веб-сайтів. За замовчуванням дані кожного конфігураційного зберігання зберігаються окремо. Всі дані конфігурації веб-сайту кешовані в одному об’єкті.

Зауважте, що це стосується лише переосмислення конфігурації [налаштування адміністратора]. Тож якщо ви зробите всі зміни конфігурації на рівні магазину, уже встановлений. Якщо ви використовуєте "успадковувати з веб-сайту" і вносите більшість змін у конфігурацію вашого магазину на рівні сайту - тоді кеш містить кожен веб-сайт. Розбивши його, ви зможете вибити його набагато краще. захищений $ _cacheSections = array ('admin' => 0, 'adminhtml' => 0, 'crontab' => 0, 'install' => 0, 'store' => 1, 'веб-сайти' => 0);

до

protected $_cacheSections = array(
    'admin'     => 0,
    'adminhtml' => 0,
    'crontab'   => 0,
    'install'   => 0,
    'stores'    => 1,
    'websites'  => 1
);