改进列表生成速度,DedeCMS负载性能优化实例,让你的织梦列表快30倍以上

2017-05-21 二次开发 浏览 手机预览
文章来源:http://www.dedecmsok.com/html/n26.html

对于DedeCMS表现出来相对较差的性能感觉比较迷惑,到底是什么在限制其负载效率?难道真的是某些Dede论坛版主说的是因为MySQL不堪重负的原因吗?

        我们通过一个实例来解析和优化DedeCMS的数据管理性能,千万别让MySQL当替罪羊。测试数据是重复添加的文章数据,数据量将近110万条。未优化前我们测试发现主要有两个经常性的操作在Dede大数据量的情况下影响管理性能,分别是“文档生成”“列表生成”,接下来我们就针对这两个方面进行优化实践。


        改进列表生成速度

        1、【问题描述】

        接下来我们继续测试列表页面的生成,这次我们学乖了,先把模板list_article.htm中的arclist标签删除后再测试,但是生成效果依然非常不理想,每个列表页面生成时间接近20秒,按照每页50条数据计算,生成单个栏目的3万数据理论上也要花费3个多小时,生成90万数据..这......。由于列表内容使用的是list标签,这是一个和arclist有点类似的标签,因此我们不能延续上一篇文章(改进文章生成速度)的做法来解决问题,只能另辟蹊径。

        2、【问题分析】

        由于目标锁定在list标签,测试的过程就简单了。我们直接使用织梦中list的查询语句做优化分析,很快发现了问题。我们测试了list中的sql查询语句,以下代码就是list用来查询数据库中对应条件的SQL语句,执行时间大约为15秒,效率很不理想。

Select arc.ID,arc.title,arc.iscommend,arc.color, arc.typeid,arc.ismake,arc.money,arc.description,arc.shorttitle, arc.memberid,arc.writer,arc.postnum,arc.lastpost, arc.pubdate,arc.senddate,arc.arcrank,arc.click,arc.litpic, tp.typedir,tp.typename,tp.isdefault,tp.defaultname, tp.namerule,tp.namerule2,tp.ispart,tp.moresite,tp.siteurl from dede_archives arc left join dede_arctype tp on arc.typeid=tp.ID left join qiye_addonarticle on arc.ID = qiye_addonarticle.aid where arc.arcrank > -1 And ( ( arc.typeid='1′ ) or arc.typeid2='1′) order by arc.sortrank desc limit 0,50

        我们注意到这个SQL语句中的where子句使用了and和or的多种条件判断,经验告诉我们如果查询子句中使用了in或者or语句,会导致全表扫描,这样的话索引的效率就无法体现。我们简化了where子句的判断条件进行测试,结果发现删除了or子句之后,查询效率大幅提升,上面的查询语句只用时不到1秒就获得了查询结果。这就是问题关键。

        3、【解决方案】

        对于list查询来说,arc.typeid2='1′这个条件目的是查找某个文章所属的第二分类(相当于副栏目),而事实上这个功能在大部分情况下很少使用,因为我们大可使用tag标签来完成一篇文章的多个不同分类的归属,因此我们修改文件inc_arclist_view.php,在查询语句中直接删除了typeid2的条件判断,并在pub_db_mysql.php中改进了查询执行函数(用于提高sql语句执行的效率,对最终结果影响不大,可以省略),得到最终的测试结果,平均每个列表页面的生成时间下降至不到1秒,3万数据600个列表页面生成只需要花费不到10分钟,优化目标达成。


        【相关推荐】

        改进文章生成速度

原文地址:http://www.dedecmsok.com/html/n26.html
  • 如果你的问题还没有解决,可以点击页面右侧的“ ”,站长收到问题后会尽快回复解决方案到你的邮箱。
  • 创造始于问题,有了问题才会思考,有了思考,才有解决问题的方法,才有找到独立思路的可能。 —— 陶行知