Problema de rendimiento con 1k a 10k sitios web / tiendas

Estoy tratando de encontrar una manera de mejorar el rendimiento de Magento cuando la cantidad de sitios web / tiendas supera 1k, y mi objetivo es de alrededor de 10k. Aquí hay algunas preguntas; ¡cualquier consejo / ayuda es extremadamente bienvenido!

1. Agregar nuevos sitios web / tiendas es lento;
   Comento $ this-> cleanModelCache () en _afterSave () en Mage_Core_Model_Abstract, y la situación parece mejor, pero cada vez es más lenta con el aumento del número de sitios web / tiendas. Y no sé qué afectaría esto a todo el sistema en el futuro.

2. Las llamadas a la API se vuelven lentas.
   Uno de los procesos principales es hacer un pedido; mi modelo personalizado lo maneja procesando algunos datos, y esencialmente usando modelos de ventas / cotizaciones y modelos de ventas / cotizaciones de servicio. El proceso comienza con Oauth. Tanto Oauth como realizar pedidos tardan más cuando crece el número de sitios web / tiendas y el consumo de memoria parece mayor. ¿Tiene esto algo que ver con que Mage cargue el xml de configuración y el hecho de que los datos de configuración aumentan con el número creciente de sitios web?

3. Abrir n98-magerun dev: la consola está tardando más; No sé la causa de esto.

4. Guardar la configuración desde el panel de administración lleva más tiempo; No sé cómo mejorarlo.

¿Es posible reconstruir la forma en que Magento genera y carga los datos de configuración para reducir su consumo de memoria? ¿Es este uno de los factores que causan problemas de rendimiento para mi situación?

Instancia actual de Magento: Versión = Magento EE 1.14.2.4;
Configurar caché activado; otro caché apagado;
Usando Mysql 5.6 y MongoDB (para catalog_category_entity, catalog_product_entity, core_website);
número de sitios web = número de tiendas = número de visitas = 1024;
número de producto = 4501;

¡Gracias a todos de antemano!

Una de las razones por las que se ralentiza es porque la configuración de cada tienda está duplicada de / config / websites y / config / global y el código para hacerlo no es eficiente en lo más mínimo. Cualquier cambio de configuración puede terminar causando varios 10's de minutos, si no horas, de rendimiento y rendimiento reducidos. Hacerlo más eficiente básicamente significará que Ben Marks te perseguirá ... y no en el buen sentido.

Si va a seguir esta ruta, la forma más fácil sería tener 10k instalaciones de Magento y tener algún tipo de agente que delegue las solicitudes en el sitio web correspondiente. Aunque, por supuesto, dependerá de cuál sea su caso de uso real.

[adicional]

Dependiendo del caso de uso, puede utilizar categorías como pseudoalmacenes. Técnicamente, podría usar el diseño XML para cambiar la temática por tienda. Pero entonces te toparías con la limitación del pago. Todas las tiendas tendrían que compartir el pago.

De cualquier manera, 10k tiendas Magento son factibles, ya que no es imposible. Pero será un camino difícil, sea cual sea el camino que elija.

Puede intentar hackear el núcleo y habilitar divisiones de caché del sitio web. Puede intentar hackear la base de datos y almacenar información de configuración en la memoria. Puede intentar reemplazar la caché de configuración con algo más inteligente, por ejemplo, almacenar en caché la información de los archivos xml [que son estáticos y se aplican a todos los sitios web y tiendas] mientras recupera los datos de anulación de forma dinámica.

Soy un tipo de servidor, así que iría con mucking con la base de datos. Especialmente porque es trivial de hacer.

Si tiene control sobre su servidor de base de datos: Cambie el nombre de la tabla core_config_data a core_config_data_offline Cree una nueva tabla core_config_data utilizando el motor de almacenamiento MEMORY http://dev.mysql.com/doc/refman/5.7/en/memory-storage-engine.html Copie todos los datos de core_config_data_offline a core_config_data

Configure un trabajo cron para verificar si existe core_config_data, si copia todos los datos de allí a core_config_data_offline. Si no es así, créelo y copie todo, desde core_config_data_offline a core_config_data

Apague la caché de configuración. Con la caché de configuración activada, solo obtienes un aumento de rendimiento por primera vez que los datos de configuración se leen de la base de datos, después de eso está en la caché y sufres. En el lado negativo, los archivos xml ya no se almacenan en caché, por lo que intercambió el impacto de rendimiento de deserializar grandes datos de configuración por el impacto de rendimiento de analizar un montón de archivos xml.

También puede experimentar con cambiar el archivo Mage / Core / Model / Config.php y habilitar cachés de sitios web individuales. Por defecto, los datos de configuración específicos de cada tienda se almacenan en caché individualmente. Todos los datos de configuración del sitio web se almacenan en caché en un objeto.

Tenga en cuenta que esto es solo para la anulación de la configuración [la configuración de administrador]. Entonces, si realiza todos los cambios de configuración en el nivel de la tienda, ya está configurado. Si está utilizando "heredar del sitio web" y está haciendo la mayor parte de los cambios de configuración específicos de su tienda a nivel de sitio, entonces el caché contiene cada sitio web. Al dividirlo puedes dividirlo mucho mejor. protected $ _cacheSections = array ('admin' => 0, 'adminhtml' => 0, 'crontab' => 0, 'install' => 0, 'stores' => 1, 'websites' => 0);

a

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