我正在运营多个Magento CE商店,并通过缓存加快速度,但是购物车和结帐仍然很慢。有没有人有加速这些页面的经验或技巧?
也许通过优化数据库?
从结帐保存订单时执行了一些查询,但确实显示在服务器上的慢查询日志中,数据库似乎确实是瓶颈。
我正在运营多个Magento CE商店,并通过缓存加快速度,但是购物车和结帐仍然很慢。有没有人有加速这些页面的经验或技巧?
也许通过优化数据库?
从结帐保存订单时执行了一些查询,但确实显示在服务器上的慢查询日志中,数据库似乎确实是瓶颈。
Answers:
从个人经验来看,请禁用Mage_Rss模块,该模块会在结帐过程中强制执行4次“缓存清理”操作-如果使用文件系统缓存,则非常昂贵;如果使用数据库或内存缓存,则可能仍然很昂贵。
仅出于类似原因,CE仅禁用Mage_Downloadable(只要您不使用Downloadable产品),当购物车中有多个商品时,这将加快结帐和购物车操作的速度,因为在诸如此类的情况下checkout_type_onepage_save_order_after
,有观察者将响应时间乘以商品数在购物车中。
连接xhprof / xhgui并进行一些分析。
Module "Enterprise_PricePermissions" requires module "Mage_Downloadable
如果您想通过实验方法解决它,可以从德国慕尼黑的第一个magento hackathon扩展一下:
https://github.com/magento-hackathon/MongoDB-OrderTransactions
他们将订单排队到mongo数据库中,这个想法是,如果mysql服务器没有负载将其写回。但是我不知道这个项目已经准备好了多长时间。Afaik负责所有写作,但不负责背面写作。
我不知道您正在努力使用的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)确实可以降低报价过程)。
也许看一下在数据库中拆分读取和写入。您将需要进行近乎即时的复制设置,尽管这可能一直让我感到担忧,尽管其他人可能对如何最好地配置它有更多的了解。