标签：des blog http java 使用 os 文件 io
依然在为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的方案，虽然效果比不上整页缓存，但胜在灵活，安全，适应性强。
个人肤浅的观点，欢迎拍砖！
magento -- 给Magento提速之缓存上的探索,布布扣,bubuko.com
标签：des blog http java 使用 os 文件 io
原文地址：http://www.cnblogs.com/focai/p/3875720.html
