dedecms负载性能优化实例，三招让你的dedecms快10倍以上第12页

当前第2页 返回上一页

解决方案3：也是小组建议的解决方案，那就是充分挖掘现有dedecms的功能，在尽量不改变程序的基础上，大幅提高效率。具体的方法就是通过freelist（自由列表生成）功能事先生成热门文章、最新文章、相关文章等内容的列表页面，然后使用dedecms提供的include标签直接引入文档页面。标签格式为：{dede:include file='列表页面文件名称' ismake=' no'/}。这个方案优点在于仅增加部分操作步骤，没有改动任何程序，性能提高亦非常明显。下图就是我们利用这个方法优化后的生成速度，仅用时50秒就完成了1500多页的文章生成，达成目标优化效果。此方案由于增加了操作步骤，懒人慎用。

优化后单个栏目文档生成速度

2.改进列表页面生成速度

问题提出

        接下来我们继续测试列表页面的生成，这次我们学乖了，先把模板（list_article.htm）中的arclist标签删除后再测试，但是生成效果依然非常不理想。如下图，每个列表页面生成时间接近20秒（我们修改了页面结果输出提示，为了大家更方便看到每个列表页面生成时间），按照每页50条数据计算，生成单个栏目的3万数据理论上也要花费3个多小时，生成90万数据……无语ing。由于列表内容使用的是list标签，这是一个和arclist有点类似的标签，因此我们不能延续上面的做法来解决问题，只能另辟蹊径。

优化前的列表页面生成速度

问题分析

        由于目标锁定在list标签，测试的过程就简单了。我们直接使用dedecms中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秒就获得了查询结果。这就是问题关键。