Magento speed optimisation

诚然,我接触Magento时间不短了,但直到最近才开始研究Magento的速度,因为我的一个Magento项目已经上马了。

通常Magento要比Zencart, osCommerce, VirtueMart for Joomla跑得慢,但这个没有吓退我。我坚信Magento是我的方向,是因为Magento的ecommerce功能是其它软件望尘莫及的,况且我拥有让Magento加速的硬件资源。(这世界上没有什么是最好的,适合自己的就是最好的)。

我认为选择Magento,首先得有一台独立服务器。虽然我曾成功地在shared hosting环境里运行了Magento,但一个没有速度优化潜力的Magento,就算能跑,又有什么用?Magento内置了很多SEO特性,但如果页面loading time过长,Google也不会喜欢。VPS理论上也能为Magento做速度优化,但一台入门级的独立服务器与一台高性能的VPS价格相当,我会选择前者,以确保所有的优化可能。

其次得有1G以上内存,CPU差一点没关系,因为Magento的速度瓶颈在硬盘,优化手法中很多就用内存代替硬盘。

有了以上两个硬件资源,剩下的就是进行一些软件环境设置。

首先,得是Linux环境。我不是说Magento在Windows下跑不起来,我是说网上大部分建议都是针对Linux提的,除非你有一个Microsoft专家在你旁边,每当你给他一个Linux配置文件,他能为你写一个Windows下的对应文件。

其次,给MySQL Server分配更多的内存。

再次,启用Cache。Cache分三种,一是Magento data cache,Magento系统菜单的Cache Management指的就是这个,默认已经启用。据我观察,data cache单独使用时,对速度提升没多大帮助。二是Linux in-memory file cache,把magento/var/cache指到或软连接到tmpfs。三是php byte cache,开源世界里主要有三种选择,php APC, eAccelerator, xCache。孰优孰劣尚无定论,我看了一些测试结果,我的结论是:小访问量时选php APC,访问量达到负载容量50%以上的选xCache,Magento的开发小组说eAccelerator在处理magento异常时会出错,我就把它剔除了。

如果以上优化都做过了,速度应该很理想了。经济条件许可的话,买多点内存,搞个SCSI, RAID硬盘,换个四核CPU,我就不信Magento会比谁慢。

34 Replies to “Magento speed optimisation”

  1. 不知道你有没有测试过Magento可以支撑大致多少并发,如果并发足够大的话,怎么办?私用集群马?如果使用集群,Magento支持吗?是否需要复杂的配置?

  2. 没有测试过最大并发数,但针对我的网站测试过10个并发,一点问题都没有。

    你说的群集,指的是web群集,还是数据库群集?我认为web群集应该在magento以外考虑,一个架构得很糟糕的web程序也很容易实现web群集;数据库群集要复杂一些,可巧这两天我在琢磨这玩意,我认为如果web程序如果本身没考虑数据库群集,从mysql方面动动脑筋,也是可以实现的。好消息是:magento架构得堪称完美,如果你仔细看看magento的配置文件,你会惊叹magento的周到。

    自从发现世界上有magento以后,我就不再关心其它的程序了。当然其它程序也在更新换代,但我敢假设在很长一段时间内,它们无法超越magento。

  3. magento功能的确强大,就是环境太难配置了,我的win服务器+apache2+php5.2.8 到现在还不能运行magento,按他的文档上,我关闭了安全模式,开启rewrite功能,能打开安装页面,填写完数据库账号密码后点击continue就页面打不开,“Firefox 检测到该服务器正在将此地址的请求循环重定向。”
    博主能不能给我点帮助啊?
    我的联系email是 chenliangc@gmail.com

  4. 在后台哪里设置? 可否介绍一下?

    另外, multi websites是支持不同的domain name,还是同一domain name的不同url?

  5. 才做好一个站,早听说magento慢,可没想到这么慢,我的是独立主机,性能一般般,可速度实在让人无法忍受啊,一般要十来秒钟才打开。楼主可以指教一二吗?请用非IE看看: shop.fivetone.cn

  6. to danefy: 不好意思,我没用过lunarpages的服务器

    to fenix: 优化可以从很多方面入手,花钱买更好的硬件是最简单的办法,按我以上说的自己动手作软件方面的调整是最通常的办法。不过最近我在学习nginx,让magento 跑在niginx上,预计效果更好。目前只是预计,等我实测了我再告诉大家。

  7. fenix 你的速度比我快一点呀, 5秒左右,我用的是美国 godaddy 主机。

    ———————————————————-
    fenix Says:
    March 4th, 2009 at 6:33 pm

    才做好一个站,早听说magento慢,可没想到这么慢,我的是独立主机,性能一般般,可速度实在让人无法忍受啊,一般要十来秒钟才打开。楼主可以指教一二吗?请用非IE看看: shop.fivetone.cn

  8. magento 1.3 在速度上有很大改善,建议大家尽快升级。因为我的模板不支持 flat catalog,所以我暂时无法使用 flat catalog。

    尽管如此,在未启用 flat catalog的情况下,magento 1.3 仍比早期版本快了很多。如果启用 flat catalog,按官方的说法,还可以有 40% 的提升,我对这样的速度已经很满意了。

  9. 看了推荐的文章,整理的优化方法比较全面,但这些方法没有什么新意了。我现在在想的是,做完了所有的常规优化,还能有什么偏门能让magento再快一点、更快一些

  10. 在bluehost下的magento速度怎么优化好点啊?
    有好的解决方案吗?
    最近正为这事弄的发愁!!

  11. 我觉得博主的想法纯粹是一厢情愿:) 你有真正试过你的方案吗?就算你所有的都用上了,可能还是不及zencart快,你思考过什么原因吗?

    只要不是整个页面缓存,你就避免不了使用magento的bootstrap过程,恰恰那个过程是相当地慢!

    如果一个页面单人访问的速度没解决好,你谈那些什么内存、多机有什么意义呢??

  12. 我一直在测试。如果一个页面单人访问的话,在入门级的vps上,常规优化(magento wiki提及的)后的magento 就可以获得非常理想的速度。当然这个速度跟zencart是没法比。

    但不能光从速度上考虑选择magento或是zencart。我会给RAD、safe upgrade等因素很高权重,给scaleability、documentation中等权重,在这些因素上,我还没看到其他ecommerce方案能好过magento。

  13. Nginx下运行mage非常快,前提是nginx针对mage的rewrite要写完美。
    nginx下是不识别.htaccess文件,全靠nginx的rewrite模块和rewrite配置文件来完成一系列的配置。
    只要mage支持的方法,nginx就会支持。mage本身的缓存机制就非常好,因为也是用的zend_cache,所以,我们可以自由地根据自己服务器的实际情况来做决定mage的缓存媒介。我用的是内存缓存,只有在首次访问时会慢一点点,因为在访问的本地机上也会做高命中地全站的内存缓存。
    这是nginx的优势之一,另,nginx的效率是apache的近10倍,用它来跑mage,只要你的服务器硬件够强悍,它就可以帮你把机能发挥到极致。

  14. Nginx对静态文件html,js,css,图片的请求很快。速度慢瓶颈在magento自身上。在网上见过一种方式是:nginx或lighthttp做前端,处理静态内容请求,很快并可以节省cpu。apache做后端,专门处理动态内容。

    Magento是耗费cpu大户,我一个网站开始只能应付36个左右并发,加了个cpu后,并发数提高一倍。

    大并发量网站,还是要依靠集群。

  15. 我觉得 Nginx 和 Apache 的请求并无快慢之分。如果说 Nginx 比 Apache 快,很多是不公平的比较,拿 Nginx 的默认配置状态与 Apache 的默认配置状态去比,当然是 Nginx 快。比如对 .htaccess 的处理,Nginx 里根本没有 .htaccess 之说,不处理 .htaccess 当然比处理要快,但怎么不想想 Apache 也可以配置成不处理任何 .htaccess,不想想 Apache 有 .htaccess 可以做 Nginx 做不了的用户级的设置 ?

    Nginx 比 Apache 的最大优势是占用内存少,在内存既定的服务器上可以支持更多的并发。我的内存有很多闲置,对我来说用 Nginx 不用 Apache 没有速度上的优势。这点结论是我从熟悉的 Apache 转投原本陌生的 Nginx 环抱后好久才总结出的。一直沿用 Nginx 是因为将来总有内存不够用的时候。

    Magento 虽是资源消耗大户,但也不至于 72 个并发就说要群集了——那什么服务器啊?赛扬 PC 都不至于如此不堪。难道是百万级的产品库?我倒没机会尝试。是不是有些基础配置没做好?在很一般的服务器上,并发 500 都应该很轻松的。

  16. Nginx比apache节省内存,很赞同你的见解。

    据说是由于apache 每个工作进程都加载了mod_php这个模块,而这个mod_php内置了php解析器,所以比较占内存。但Nginx的优点不仅仅在于节省内存,比较一致的说法是他采用更先进的网络i/o模型,支持的并发数大,特别对于处理静态文件优势更明显,用google可以详细了解。

    另外, 我没说“72个并发就要上集群”, 我的原话是“大并发量网站,还是要依靠集群”。

    我们的机器是1.5w左右的配置,也算很一般的服务器上,但实际用ab测试,并发100勉强,再提高并发的话,请求响应时间就达到2秒以上了,没什么意义。

    至于500的并发,估计要上什么full page cache才能达到。

    下面是一篇测试Magento . Apache . Nginx的文章,虽然测试不一定准确,但总的说来给了一个大致的比较。可做参考:
    yaozer.cn/apache-nginx%E6%80%A7%E8%83%BD%E6%AF%94%E8%BE%83-nginx%E5%AE%8C%E8%83%9C/

  17. hi

    我使用了apc,但是效果不是很明显,主要是website 很大,里面的observer / rewrite 也不少。

    有没有什么好的 full page cache 的建议。我一直研究cache 这块,但是被动式 cache ,还不是太理想。

  18. 当年我说得比较绝对,其实VPS也能跑出很好的Magento,Lunarpages的VPS好不好不好说,但512嘛,显然是不够的。Lunarpages价格好像还挺贵,在别的地方都可以买4G以上了。话说回来,稳定是最主要的,价格是其次。我遇到太多rubbish VPS providers,所以有此感慨。

Leave a Reply

Your email address will not be published. Required fields are marked *