magento -- 给Magento提速之缓存上的探索

简介:

依然在为Magento提速做努力,除了自带的缓存和编译,之前的所作的很多努力都是从减少JS,Css,图片等载入时间入手,而对页面载入耗时最早有时也是最大的一部分--获取页面数据没有做太多处理,以gap.cn为例,用firebug看下各个请求的耗时(数据受多方面因素影响,仅供参考):

 

可以看到js和css的载入时间一般是以几十毫秒来计算的,而载入的第一步页面数据却要花掉将近一秒,在用各种方法缩短js,css和图片的载入时间后,想要让Magento跑的更快,就得想办法从缩短这“781ms”处下手。

 

因为Magento复杂的代码架构和EAV模式的数据库,导致每次页面载入都要读取大量的php文件和大量的数据表,自带的缓存将一些常用的数据缓存到了文件里,而不需要每次都去读取数据库,这提醒了我们一种思路,就是将页面上常用的数据都缓存起来,减少读取php文件和数据库的需要。不记得在哪里看到过一篇文章提到,Magento自带的缓存方案相当保守,缓存的数据很少,页面载入时依然要从数据库读取大量的数据。我们所要做的就是改进缓存的方案,将更多数据缓存到文件中去。

 

我对缓存的研究不是很深,个人理解大概分两种,一种是整页缓存,一种是局部缓存,以我测试过的两个缓存插件为例阐述下观点。

 

第一个插件是一个整页缓存的插件--Performance Booster,官网上的地址是http://www.magentocommerce.com/magento-connect/AITOC,+Inc./extension/4865/performance_booster,这个插件开启后,会在前台每访问一个页面后就生成一个静态html,下次再访问相同页面时会直接读取静态文件的内容,速度提升相当明显,能将第一步html的载入时间从几百毫秒直接提升到几十毫秒。这个插件的代码里监听了一大堆事件,用来刷新缓存,比如后台修改产品信息后保持的时候会刷新对应的缓存。

 

按说这个插件已经将可能需要刷新缓存的状况都考虑到了,但我在使用的时候却遇到了麻烦。因为Magento是个高度开放的系统,可以安装各种各样的第三方插件,也可以自己写一些新模块进去。插件不可能考虑到除了系统自带模块以外需要刷新缓存的情况,这就导致了页面某些部分在后台数据已经改变的情况下前台没有刷新或者有一些功能块直接出现异常无法使用。而我所经手的项目大多都装有不少插件,以及自己所做的修改,所以很难有机会用上这个插件了。

 

第二个插件是一个免费插件--CatalogCache,官网上的地址是http://www.magentocommerce.com/magento-connect/netresearch/extension/2138/catalogcache,这个插件功能很简单,就是缓存了Catalog/Product_View和Catalog/Product_List这两个block的数据,对页面上来说,也就是缓存了产品列表页的产品数据和产品详细页的产品数据,只缓存局部,而不是整个页面。经测试,在产品数比较多的列表页和产品页,开启这个插件后能带来大概100ms--到200ms不等的速度提升。因为只缓存了两个block,所以插件也只对列表页和产品页起效果。

 

这个插件功能简单,针对性强,所以也不用担心会对列表页和产品页以外的东西造成影响,经过一段时间测试没问题后已经用在了正式的项目上。当然推荐这个插件并不是这篇文章的主要目的,而是这个插件让我觉得用同样的方式给各种常用block写缓存是种安全而又实用的方式,虽然效果上肯定比不上直接读静态文件来得快,但因为是自己一块块写的,不需要担心整页缓存时会有哪一块遗漏了没有照顾到。也就是说,不管你添加了多少第三方插件,或者自己写了多少功能,依然可以用这种方式来做优化,自己选择性的给局部做缓存。

 

得出我自己的观点,整页缓存的适应性不够好,无法应对各种不同的项目情况,如果你的Magento站只是在默认功能上套了个模板,可以尝试下第一个插件,如果项目有不少第三方插件,甚至做了不少二次开发,那么就放弃整页缓存方案。所以局部缓存才是我认为最适合Magento的方案,虽然效果比不上整页缓存,但胜在灵活,安全,适应性强。

 

个人肤浅的观点,欢迎拍砖!

目录
相关文章
|
自然语言处理 算法 大数据
Python大数据:jieba分词,词频统计
实验目的 学习如何读取一个文件 学习如何使用DataFrame 学习jieba中文分词组件及停用词处理原理 了解Jupyter Notebook 概念 中文分词 在自然语言处理过程中,为了能更好地处理句子,往往需要把句子拆开分成一个一个的词语,这样能更好的分析句子的特性,这个过程叫就叫做分词。
9555 0
|
JavaScript 应用服务中间件 Shell
转码服务器
ffmpeg
2092 0
|
开发工具 git
部署hexo遇到报错ERROR Deployer not found: git的解决办法
部署hexo遇到报错ERROR Deployer not found: git的解决办法
876 0
poi 生成word 表格,并向表格单元格中插入多个图片
poi 生成word 表格,并向表格单元格中插入多个图片
642 0
poi 生成word 表格,并向表格单元格中插入多个图片
|
流计算 Apache 分布式计算
带你读《Flink原理、实战与性能优化》之一:Apache Flink介绍
这是一部以实战为导向,能指导读者零基础掌握Flink并快速完成进阶的著作,从功能、原理、实战和调优等4个维度循序渐进地讲解了如何利用Flink进行分布式流式应用开发。作者是该领域的资深专家,现就职于第四范式,曾就职于明略数据。
|
算法 数据挖掘 知识图谱
基于品类关系,虚拟类目如何建设?
类目-属性项-属性值体系(简称CPV)是淘宝建设中非常重要的基石,在商品的发布、管理,以及搜索场景下都大量应用。比如每个商品都有自己的类目、以及属性,而且需要发布在适合自己的类目下,才能够方便管理和搜索;在用户搜索的过程中,对Query的类目预测也是相关性中非常重要的一环。
6020 0
|
SQL 存储 分布式计算
Flink 的应用场景和架构模型
在过去的十年里,面向数据时代的实时计算技术接踵而至。从我们最初认识的 Storm,再到 Spark 的异军突起,迅速占领了整个实时计算领域。直到 2019 年 1 月底,阿里巴巴内部版本 Flink 正式开源!一石激起千层浪,Flink 开源的消息立刻刷爆朋友圈,整个大数据计算领域一直以来由 Spark 独领风骚,瞬间成为两强争霸的时代。 Apache Flink(以下简称 Flink)以其先进的设计理念、强大的计算能力备受关注,如何将 Flink 快速应用在生产环境中,更好的与现有的大数据生态技术完美结合,充分挖掘数据的潜力,成为了众多开发者面临的难题。
1695 0
Flink 的应用场景和架构模型
|
存储 机器学习/深度学习 缓存
个推消息中心如何实现多渠道消息智能下发?
个推爆款产品【消息中心】如何满足金融、互联网等典型行业客户的多渠道消息智能下发需求?本文介绍了消息中心的技术架构。
839 0
个推消息中心如何实现多渠道消息智能下发?
|
移动开发 小程序 前端开发
飞猪微信小程序建设总结
飞猪对小程序业务的尝试是比较早的,随着支付宝小程序的出现飞猪的各条业务线都在不断尝试小程序化以更好的在支付宝端获客、触达、留存,但是因为众所周知的原因飞猪一直没有尝试过微信小程序。随着21年反垄断的风越吹越盛,阿里的一些业务开始在微信领域伸出了触角,飞猪也随势而动尝试开垦“微信小程序”这块对我们来说是“处女地”的地方。
1949 0
飞猪微信小程序建设总结
|
域名解析 存储 缓存
基于OSS作为存储实现加速访问和加速上传的方案实现
本文通过实现OSS加速的两种方式CDN加速OSS和OSS传输加速来介绍OSS的加速的配置实现方式
8261 0
基于OSS作为存储实现加速访问和加速上传的方案实现