Ускорение корзины до оформления заказа и сохранения сохраненных действий

Я управляю несколькими магазинами Magento CE и ускоряю их кэшированием, однако корзина и оформление заказа все еще остаются медленными. У кого-нибудь есть опыт или советы по ускорению этих страниц?

Возможно, за счет оптимизации базы данных?

Некоторые запросы были выполнены при сохранении заказа из оформления заказа, которые отображаются в журнале медленных запросов на сервере, и база данных кажется узким местом.

1. Исходя из личного опыта, отключите модуль Mage_Rss, который заставляет «очищать кеш» 4 раза в процессе извлечения - очень дорого, если вы используете кеш файловой системы, вероятно, все еще дорого, если вы используете базу данных или memcached.

2. Только для CE Отключить Mage_Downloadable по тем же причинам, если вы не используете загружаемый продукт, это ускорит оформление заказа и действия корзины, если в корзине несколько товаров, поскольку есть такие наблюдатели, checkout_type_onepage_save_order_afterкоторые умножают время ответа на количество элементов в корзине

3. Подключите xhprof / xhgui и выполните профилирование.

• Установите ваши индексы на ручной.
• Отключить хранение тегов кеша

Оба эти изменения окажут МАССИВНОЕ влияние на производительность, поскольку это предотвратило очистку кэшей Magento и повторную индексацию при каждом выполнении заказа.

Тем не менее, это может привести к тому, что в результате контент может устареть - уровень запасов и т. Д.

Если вы хотите решить это экспериментальным путем, есть расширение от первого хакатона magento в Мюнхене, немецкий:

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

Идея заключалась в том, что они помещают заказы в очередь в mongo db, если mysql-сервер свободен для их обратной записи. Но я не знаю, насколько этот проект готов. Афайк работает над всем письмом, но не надписью.

Я не знаю вашу версию Magento CE, с которой вы боретесь. Но у меня были серьезные проблемы с производительностью моего CE 1.6.
Причина: неверные и отсутствующие индексы. Они были исправлены в CE 1.6.2.
Вы можете проверить, помогает ли это вам.
Я сократил время оформления заказа на 38 строк с 73 предметами в общей сложности с 123 до 4 секунд !!!!

Вот оно:

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

Лучший способ ускорить работу с большими базами данных - это иметь базу данных на своем собственном сервере, оптимизированном для использования базы данных. С точки зрения кода можно немного улучшить что-либо в области оформления заказа (хотя некоторые типы продуктов, такие как Configurable, действительно могут затормозить процесс цитирования), поскольку очень мало можно безопасно кэшировать.

Может быть, посмотрите на разделение чтения и записи в вашей БД. Вам понадобится почти немедленная настройка репликации, хотя это всегда беспокоило меня, хотя у других может быть больше информации о том, как лучше настроить.