Acelerando o carrinho para fazer checkout e salvar ações

Estou executando várias lojas Magento CE e as acelero com cache, no entanto, o carrinho e o checkout ainda permanecem lentos. Alguém tem experiência ou dicas para acelerar essas páginas?

Talvez através da otimização do banco de dados?

Algumas consultas foram executadas ao salvar um pedido no checkout e aparecem no log lento de consultas no servidor, e o banco de dados parece ser o gargalo.

1. Por experiência pessoal, desative o módulo Mage_Rss, que força um 'cache limpo' 4 vezes no processo de checkout - muito caro se você estiver usando o cache do sistema de arquivos, provavelmente ainda caro se você estiver usando o banco de dados ou o cache de memórias.

2. Desabilitar apenas Mage_Downloadable da CE por razões semelhantes, desde que você não esteja usando o produto para download, isso agilizará as ações de checkout e carrinho quando você tiver vários itens no carrinho, pois existem observadores sobre coisas como o checkout_type_onepage_save_order_afterque multiplicam o tempo de resposta pelo número de itens no carrinho.

3. Conecte o xhprof / xhgui e faça alguns perfis.

• Defina seus índices para manual.
• Desativar armazenamento de tags de cache

Ambas as alterações terão um impacto enorme no desempenho, pois impedem o Magento de liberar caches e reindexar toda vez que um pedido é processado.

Porém, o custo pode ser que o conteúdo seja obsoleto - níveis de estoque etc.

Se você quiser resolvê-lo da maneira experimental, há uma extensão da primeira hackathon magento em munique, alemão:

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

Eles enfileiram os pedidos em um mongo db, a idéia era, se o servidor mysql estiver livre de carga para escrevê-los de volta. Mas não sei até que ponto esse projeto está pronto. Afaik trabalha toda a escrita, mas não a escrita posterior.

Eu não conheço sua versão do Magento CE com a qual você está lutando. Mas tive sérios problemas de desempenho com o meu CE 1.6.
Razão: índices errados e ausentes. Eles foram corrigidos no CE 1.6.2.
Você pode verificar se isso ajuda.
Reduzi o tempo de check-out de 38 linhas com um total de 73 itens de 123 para 4 segundos !!!!

Aqui vem:

/*!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 */;

A melhor maneira de acelerar as operações de grandes bancos de dados é ter seu banco de dados em seu próprio servidor, otimizado para uso do banco de dados. Não há muito que possa ser aprimorado na área de checkout em termos de código (embora certos tipos de produtos, como o Configurable, possam realmente atrapalhar o processo de cotação), pois muito pouco pode ser armazenado em cache com segurança.

Talvez divida as leituras e as gravações no seu banco de dados. Você precisará configurar a replicação quase imediata, o que sempre me preocupa em fazê-lo, embora outros possam ter mais informações sobre a melhor forma de configurá-lo.