Accelerare il carrello per effettuare il checkout e eseguire il checkout delle azioni di salvataggio

Sto gestendo diversi negozi Magento CE e li accelero con la memorizzazione nella cache, tuttavia il carrello e il checkout rimangono ancora lenti. Qualcuno ha esperienza o suggerimenti per accelerare queste pagine?

Forse attraverso l'ottimizzazione del database?

Alcune query eseguite durante il salvataggio di un ordine dal checkout vengono visualizzate nel log delle query lente sul server e il database sembra essere il collo di bottiglia.

1. Per esperienza personale, disabilita il modulo Mage_Rss che impone una 'pulizia della cache' 4 volte nel processo di checkout - molto costoso se stai usando la cache del filesystem, probabilmente ancora costoso se stai usando database o memcached.

2. CE Disabilita Mage_Downloadable per motivi simili purché non si stia utilizzando un prodotto scaricabile, questo accelera il checkout e le azioni del carrello quando si hanno più articoli nel carrello perché ci sono osservatori su cose come checkout_type_onepage_save_order_afterche moltiplicano il tempo di risposta per il numero di articoli nel carrello.

3. Collega xhprof / xhgui e crea un profilo.

• Imposta gli indici su manuale.
• Disabilita l'archiviazione dei tag cache

Entrambe queste modifiche avranno un impatto MASSIVO sulle prestazioni poiché impediscono a Magento di svuotare le cache e di reindicizzare ogni volta che un ordine viene eseguito.

Tuttavia, il costo potrebbe essere stantio di conseguenza - livelli di scorte ecc.

Se vuoi risolverlo in modo sperimentale, c'è un'estensione dal primo hackathon magento a monaco di baviera, tedesco:

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

Mettono in coda gli ordini in un mongo db, l'idea era, se il mysql-server è libero di riscriverli. Ma non so fino a che punto sia pronto questo progetto. Afaik lavora tutta la scrittura, ma non quella posteriore.

Non conosco la tua versione di Magento CE con cui stai lottando. Ma ho avuto seri problemi di prestazioni con il mio CE 1.6.
Motivo: indici errati e mancanti. Sono stati corretti in CE 1.6.2.
Potresti verificare se ti aiuta.
Ho ridotto il tempo di checkout per 38 righe con 73 articoli in totale da 123 sec a 4 sec !!!!

Ecco che arriva:

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

Il modo migliore per accelerare le operazioni di database di grandi dimensioni è di avere il database sul proprio server ottimizzato per l'uso del database. Non c'è molto che possa essere migliorato nell'area di pagamento in termini di codice (anche se alcuni tipi di prodotti, come Configurabile, possono davvero impantanare il processo di quotazione) poiché pochissimo può essere memorizzato nella cache in modo sicuro.

Forse guarda a dividere le letture e le scritture nel tuo DB. Avrai bisogno di una configurazione di replica quasi immediata, anche se è quello che mi preoccupa sempre farlo, anche se altri potrebbero avere maggiori informazioni su come configurarlo al meglio.