Przyspieszenie koszyka do kasy i zapisywanie działań zapisywania

Prowadzę kilka sklepów Magento CE i przyspieszam je dzięki buforowaniu, jednak wózek i kasa nadal pozostają wolne. Czy ktoś ma doświadczenie lub wskazówki dotyczące przyspieszenia tych stron?

Być może poprzez optymalizację bazy danych?

Niektóre zapytania zostały wykonane podczas zapisywania zamówienia z kasy nie pojawiają się w dzienniku powolnych zapytań na serwerze, a baza danych wydaje się być wąskim gardłem.

1. Z własnego doświadczenia wyłącz moduł Mage_Rss, który wymusza 4-krotne wyczyszczenie pamięci podręcznej podczas procesu kasowania - jest to bardzo kosztowne, jeśli używasz pamięci podręcznej systemu plików, prawdopodobnie nadal drogie, jeśli korzystasz z bazy danych lub memcached.

2. Wyłącz tylko CE Mage_Downloadable z podobnych powodów, o ile nie korzystasz z produktu do pobrania, przyspieszy to kasę i działania w koszyku, gdy masz wiele przedmiotów w koszyku, ponieważ są obserwatorzy takich rzeczy, jak checkout_type_onepage_save_order_afterczas pomnożony przez liczbę elementów w wózku.

3. Połącz xhprof / xhgui i zrób profilowanie.

• Ustaw swoje indeksy na ręczne.
• Wyłącz przechowywanie znaczników pamięci podręcznej

Obie te zmiany będą MASYWNIE wpływały na wydajność, ponieważ zapobiegały Magento opróżniając pamięci podręczne i ponownie indeksując za każdym razem, gdy zamówienie jest realizowane.

Kosztem jest jednak to, że zawartość może być nieaktualna - poziomy zapasów itp.

Jeśli chcesz rozwiązać to w sposób eksperymentalny, istnieje rozszerzenie z pierwszego hackathonu Magento w Monachium, niemiecki:

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

Kolejkują zamówienia do bazy danych mongo, pomysł polegał na tym, że jeśli serwer mysql jest wolny od obciążenia, aby je odpisać. Ale nie wiem, jak daleko ten projekt jest gotowy. Afaik zajmuje się pisaniem, ale nie pisaniem wstecz.

Nie znam twojej wersji Magento CE, z którą się zmagasz. Ale miałem poważne problemy z wydajnością z moim CE 1.6.
Powód: błędne i brakujące indeksy. Są one ustalone w CE 1.6.2.
Możesz sprawdzić, czy to ci pomaga.
Skróciłem czas realizacji 38 linii z 73 pozycjami łącznie z 123 sekund do 4 sekund !!!!

Oto nadchodzi:

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

Najlepszym sposobem na przyspieszenie dużych operacji na bazie danych jest posiadanie bazy danych na własnym serwerze zoptymalizowanym pod kątem korzystania z bazy danych. Niewiele można poprawić w obszarze kasowym pod względem kodu (chociaż niektóre typy produktów, takie jak Konfigurowalne, mogą naprawdę utrudnić proces wyceny), ponieważ bardzo niewiele można bezpiecznie buforować.

Może popatrz na podział odczytów i zapisów w swojej bazie danych. Będziesz jednak potrzebował niemal natychmiastowej konfiguracji replikacji, co zawsze mnie martwiło, chociaż inni mogą mieć więcej informacji na temat tego, jak najlepiej ją skonfigurować.