Ускорение доставки корзины до оформления заказа и сохранение действий при оформлении заказа
Я запускаю несколько магазинов Magento CE и ускоряю их с помощью кэширования, однако корзина и оформление заказа по-прежнему остаются медленными. Есть ли у кого-нибудь опыт или советы по ускорению этих страниц?
Возможно, за счет оптимизации базы данных?
Некоторые запросы, выполненные при сохранении заказа с момента оформления заказа, отображаются в журнале медленных запросов на сервере, и база данных, похоже, является узким местом.
6 answers
Исходя из личного опыта, отключите модуль Mage_Rss, который заставляет "очищать кэш" 4 раза в процессе оформления заказа - очень дорого, если вы используете кэш файловой системы, возможно, все еще дорого, если вы используете базу данных или memcached.
CE Только Отключите Mage_Downloadable по аналогичным причинам, если вы не используете загружаемый продукт, это ускорит действия по оформлению заказа и корзине, когда у вас в корзине несколько товаров, потому что есть наблюдатели за такими вещами, как
checkout_type_onepage_save_order_after
, которые умножают время отклика на количество товаров в корзине.Подключите xhprof/xhgui и выполните некоторое профилирование.
- Установите индексы вручную.
- Отключить хранение тегов кэша
Оба эти изменения окажут ОГРОМНОЕ влияние на производительность, поскольку это предотвратит удаление кэшей Magento и повторную индексацию при каждом выполнении заказа.
Это обходится дорого, хотя в результате контент может быть устаревшим - уровень запасов и т. Д.
Если вы хотите решить эту проблему экспериментальным путем, есть расширение от первого хакатона magento в Мюнхене, германия:
Https://github.com/magento-hackathon/MongoDB-OrderTransactions
Они помещают заказы в очередь в базу данных mongo, идея заключалась в том, чтобы, если 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 */;
Лучший способ ускорить операции с большими базами данных - это разместить вашу базу данных на собственном сервере, оптимизированном для использования в базе данных. В области оформления заказа с точки зрения кода мало что можно улучшить (хотя некоторые типы продуктов, такие как настраиваемые, действительно могут затруднить процесс цитирования), поскольку очень мало можно безопасно кэшировать.
Возможно, посмотрите на разделение операций чтения и записи в вашей БД. Вам потребуется почти немедленная настройка репликации, хотя именно это меня всегда беспокоило, хотя у других может быть больше информации о том, как ее лучше настроить.