Acelerar el carrito para finalizar y finalizar la compra guardar acciones

Estoy ejecutando varias tiendas Magento CE y las acelero con el almacenamiento en caché, sin embargo, el carrito y el pago siguen siendo lentos. ¿Alguien tiene experiencia o consejos para acelerar estas páginas?

¿Quizás a través de la optimización de la base de datos?

Algunas consultas se realizaron al guardar un pedido de la caja si aparecen en el registro lento de consultas en el servidor y la base de datos parece ser el cuello de botella.

1. Por experiencia personal, deshabilite el módulo Mage_Rss que obliga a una 'limpieza de caché' 4 veces en el proceso de pago, muy costoso si está utilizando caché del sistema de archivos, probablemente aún costoso si está utilizando una base de datos o memcached.

2. CE Solo deshabilita Mage_Downloadable por razones similares, siempre que no estés usando un producto descargable, esto acelerará las acciones de pago y compra cuando tengas varios artículos en el carrito porque hay observadores en cosas como las checkout_type_onepage_save_order_afterque multiplican el tiempo de respuesta por el número de artículos en el carrito.

3. Conecte xhprof / xhgui y haga algunos perfiles.

• Establezca sus índices en manual.
• Deshabilitar el almacenamiento de etiquetas de caché

Ambos cambios tendrán un impacto MASIVO en el rendimiento, ya que impidió que Magento eliminara los cachés y volviera a indexar cada vez que se realiza un pedido.

Sin embargo, tiene un costo, como resultado, el contenido puede ser obsoleto: niveles de existencias, etc.

Si desea resolverlo de forma experimental, hay una extensión del primer hackathon de magento en munich, alemán:

https://github.com/magento-hackathon/MongoDB-OrderTransactions

Ponen las órdenes en cola en una base de datos mongo, la idea era, si el servidor mysql no tiene carga para escribirlas. Pero no sé hasta qué punto está listo este proyecto. Afaik trabaja toda la escritura, pero no la escritura posterior.

No conozco tu versión Magento CE con la que estás luchando. Pero tuve serios problemas de rendimiento con mi CE 1.6.
Motivo: índices incorrectos y faltantes. Se arreglaron en CE 1.6.2.
Puede verificar si le ayuda.
¡Reduje el tiempo de pago para 38 líneas con 73 artículos en total de 123 segundos a 4 segundos!

Aquí viene:

/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;

/* Foreign Keys must be dropped in the target to ensure that requires changes can be done*/

ALTER TABLE `core_url_rewrite` 
DROP FOREIGN KEY `FK_CORE_URL_REWRITE_CTGR_ID_CAT_CTGR_ENTT_ENTT_ID`  , 
DROP FOREIGN KEY `FK_CORE_URL_REWRITE_STORE_ID_CORE_STORE_STORE_ID`  ;


/* Alter table in target */
ALTER TABLE `catalog_category_entity_varchar` 
DROP KEY `MAGMI_CCEV_OPTIMIZATION_IDX` ;


/* Alter table in target */
ALTER TABLE `catalog_product_bundle_stock_index` 
DROP KEY `PRIMARY`, ADD PRIMARY KEY(`entity_id`,`website_id`,`stock_id`,`option_id`) ;


/* Alter table in target */
ALTER TABLE `catalog_product_entity_media_gallery` 
DROP KEY `MAGMI_CPEM_OPTIMIZATION_IDX` ;


/* Alter table in target */
ALTER TABLE `core_url_rewrite` 
CHANGE `id_path` `id_path` varchar(255)  COLLATE utf8_general_ci NULL COMMENT 'Id Path' after `store_id` , 
CHANGE `request_path` `request_path` varchar(255)  COLLATE utf8_general_ci NULL COMMENT 'Request Path' after `id_path` , 
CHANGE `target_path` `target_path` varchar(255)  COLLATE utf8_general_ci NULL COMMENT 'Target Path' after `request_path` , 
CHANGE `is_system` `is_system` smallint(5) unsigned   NULL DEFAULT 1 COMMENT 'Defines is Rewrite System' after `target_path` , 
CHANGE `options` `options` varchar(255)  COLLATE utf8_general_ci NULL COMMENT 'Options' after `is_system` , 
CHANGE `description` `description` varchar(255)  COLLATE utf8_general_ci NULL COMMENT 'Deascription' after `options` , 
CHANGE `category_id` `category_id` int(10) unsigned   NULL COMMENT 'Category Id' after `description` , 
CHANGE `product_id` `product_id` int(10) unsigned   NULL COMMENT 'Product Id' after `category_id` , 
ADD KEY `FK_CORE_URL_REWRITE_PRODUCT_ID_CATALOG_CATEGORY_ENTITY_ENTITY_ID`(`product_id`) , 
DROP KEY `FK_CORE_URL_REWRITE_PRODUCT_ID_CATALOG_PRODUCT_ENTITY_ENTITY_ID` , 
ADD CONSTRAINT `FK_CORE_URL_REWRITE_PRODUCT_ID_CATALOG_CATEGORY_ENTITY_ENTITY_ID` 
FOREIGN KEY (`product_id`) REFERENCES `catalog_product_entity` (`entity_id`) ON DELETE CASCADE ON UPDATE CASCADE , 
DROP FOREIGN KEY `FK_CORE_URL_REWRITE_PRODUCT_ID_CATALOG_PRODUCT_ENTITY_ENTITY_ID`  ;


/* Alter table in target */
ALTER TABLE `eav_attribute` 
DROP KEY `MAGMI_EA_CODE_OPTIMIZATION_IDX` ;


/* Alter table in target */
ALTER TABLE `eav_attribute_option_value` 
DROP KEY `MAGMI_EAOV_OPTIMIZATION_IDX` ;


/* The foreign keys that were dropped are now re-created*/

ALTER TABLE `core_url_rewrite` 
ADD CONSTRAINT `FK_CORE_URL_REWRITE_CTGR_ID_CAT_CTGR_ENTT_ENTT_ID` 
FOREIGN KEY (`category_id`) REFERENCES `catalog_category_entity` (`entity_id`) ON DELETE CASCADE ON UPDATE CASCADE , 
ADD CONSTRAINT `FK_CORE_URL_REWRITE_STORE_ID_CORE_STORE_STORE_ID` 
FOREIGN KEY (`store_id`) REFERENCES `core_store` (`store_id`) ON DELETE CASCADE ON UPDATE CASCADE ;

/*!40014 SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS */;

La mejor manera de acelerar las operaciones de la gran base de datos es tener su base de datos en su propio servidor que esté optimizado para su uso. No hay mucho que se pueda mejorar en el área de pago en términos de código (aunque ciertos tipos de productos, como Configurable, realmente pueden atascar el proceso de cotización) ya que muy poco se puede almacenar en caché de forma segura.

Tal vez considere dividir las lecturas y las escrituras en su base de datos. Sin embargo, necesitará una configuración de replicación casi inmediata, que es lo que siempre me preocupa de hacerlo, aunque otros pueden tener más información sobre la mejor manera de configurarlo.