Прискорення кошика для оформлення касових і касових дій збереження

Я запускаю кілька магазинів Magento CE і прискорюю їх кешування, однак кошик і каси залишаються повільними. Хтось має досвід чи поради щодо прискорення цих сторінок?

Можливо, через оптимізацію бази даних?

Деякі запити виконувались під час збереження замовлення з каси, з'являючись у повільному журналі запитів на сервері, і база даних, здається, є вузьким місцем.

1. З особистого досвіду відключіть модуль Mage_Rss, який змушує "очистити кеш" 4 рази в процесі оформлення замовлення - дуже дорого, якщо ви використовуєте кеш файлової системи, ймовірно, все ще дорогий, якщо ви використовуєте базу даних або запам’ятовували.

2. Тільки CE відключити Mage_Downloadable з подібних причин, якщо ви не використовуєте завантажуваний продукт, це пришвидшить оформлення замовлення та дії у кошику, коли у кошику є кілька предметів, оскільки є спостерігачі за такими речами, checkout_type_onepage_save_order_afterякі примножують час відгуку на # елементи у візку.

3. Підключіть xhprof / xhgui і зробіть кілька профілів.

• Встановіть ваші індекси вручну.
• Вимкнути сховище тегів кеша

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

Однак це означає, що вміст може бути несвіжим - рівень запасів тощо.

Якщо ви хочете вирішити це експериментальним способом, є розширення від першого хакатона magento в мюнхені, німецькою мовою:

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

Вони чекають замовлення в 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 */;

Найкращий спосіб прискорити великі операції з базою даних - це мати свою базу даних на власному сервері, оптимізованому для використання в базі даних. Поліпшити в зоні оформлення каси не так вже й багато (хоча певні типи продуктів, як-от Конфігуруваний, дійсно можуть забруднити процес котирування), оскільки дуже мало їх можна безпечно кешувати.

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