Проблемы с производительностью от 1 000 до 10 000 веб-сайтов / магазинов

Я пытаюсь найти способ улучшить производительность Magento, когда количество сайтов / магазинов превышает 1 тыс., А моя цель - около 10 тыс. Вот несколько вопросов; любые советы / подсказки приветствуются!

1. Добавление новых сайтов / магазинов идет медленно;
   Я закомментирую $ this-> cleanModelCache () в _afterSave () в Mage_Core_Model_Abstract, и ситуация кажется лучше, но становится все медленнее с увеличением количества сайтов / магазинов. И я не знаю, что это повлияет на всю систему в будущем.

2. Api звонки становятся медленными.
   Одним из основных процессов является размещение заказа; Моя настраиваемая модель работает с ней, обрабатывая некоторые данные и, в основном, используя модели sales / quote и модели sales / service_quote. Процесс начинается с Oauth. И Oauth, и размещение заказа занимают больше времени, когда количество сайтов / магазинов растет, а потребление памяти кажется больше. Имеет ли это какое-то отношение к загрузке Mage config xml и тому факту, что данные конфигурации увеличиваются с увеличением количества веб-сайтов?

3. Открытие n98-magerun dev: консоль занимает больше времени; не знаю причину этого.

4. Сохранение конфигурации из панели администратора занимает больше времени; не знаю как это улучшить.

Можно ли восстановить способ генерации и загрузки данных конфигурации Magento, чтобы снизить потребление памяти? Является ли это одним из факторов, вызывающих проблемы с производительностью в моей ситуации?

Текущий экземпляр Magento: Версия = Magento EE 1.14.2.4;
Кэш конфигурации включен; другой кеш выключен;
Использование Mysql 5.6 и MongoDB (для catalog_category_entity, catalog_product_entity, core_website);
количество сайтов = количество магазинов = количество просмотров = 1024;
номер продукта = 4501;

Спасибо всем заранее!

Одна из причин, по которой он работает медленно, заключается в том, что конфигурация для каждого магазина дублируется из / config / website и / config / global, а код для этого неэффективен. Любое изменение настроек может привести к снижению производительности и пропускной способности на несколько десятков минут, если не часов. Повышение его эффективности в основном будет означать, что Бен Маркс придет за вами ... и не в хорошем смысле.

Если вы собираетесь пойти по этому пути, проще всего было бы установить 10k Magento и иметь своего рода брокера, который делегирует запросы на соответствующий веб-сайт. Хотя, конечно, это будет зависеть от того, каков ваш реальный вариант использования.

[Добавлено]

В зависимости от варианта использования вы можете использовать категории в качестве псевдо-магазинов. Затем вы можете технически использовать макет XML для изменения темы для магазина. Но тогда вы столкнетесь с ограничением оформления заказа. Все магазины должны будут разделить заказ.

В любом случае, магазины 10k Magento выполнимы, в этом нет ничего невозможного. Но это будет трудный путь, какой бы путь вы ни выбрали.

Вы можете попробовать взломать ядро ​​и включить разбиение кеша сайта. Вы можете попробовать взломать базу данных и сохранить информацию о конфигурации в памяти. Вы можете попробовать заменить кэш конфигурации чем-то более умным - скажем, кэширование информации из файлов 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 и включить отдельные кэши веб-сайтов. По умолчанию каждый конкретный магазин данных конфигурации кешируется индивидуально. Все данные конфигурации сайта кэшируются в одном объекте.

Обратите внимание, что это только для переопределения конфигурации [настройки администратора]. Так что, если вы сделаете все свои изменения конфигурации на уровне магазина, ваш уже установлен. Если вы используете «унаследовать от веб-сайта» и вносите большую часть изменений конфигурации вашего магазина на уровне сайта - тогда кэш содержит каждый веб-сайт. Разделив его, вы можете разбить его намного лучше. protected $ _cacheSections = array ('admin' => 0, 'adminhtml' => 0, 'crontab' => 0, 'install' => 0, 'stores' => 1, 'website' => 0);

в

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