DEDECMS负载能力优化

现在dede数据只要超过10w效率就开始下降。到了50w。简直跑不动
看了2007的改进列表也没有改进这个问题。不过blt已经正式成立公司,08版本应该会改进的
于是只能自己下手改动。越改越头痛。于是基本重写了影响效率的几个类
inc_archives_view.php
inc_arclist_view.php
inc_arcsearch_view.php
inc_arcpart_view.php
效率低下主要有几个地方
第一、arclist类中间取文章总数本来可以一句sql搞定的。blt搞了两边。
取掉count(*)的sql直接在取数据的sql里面 SQL_CALC_FOUND_ROWS
查出数据之后GetOne(“Select FOUND_ROWS()”);得到记录总数。这样list速度提高50%左右
第二、如果你的网站不收费,arcrank,money都可以在上诉几个lei里面去掉。因为一个sql的where里面多一个”>”,速度慢的多。
第三、用冗余数据换取性能,比如arc的 url。可以自己在dede_archives表里面增加字段来存储。不需要每次list的再重复构造。
第四、变换少的数据,可以实用mysql的缓存SQL_CACHE。
第五、搜索,dede的写法效率低的我想哭,like来like去的,全部删除,使用mysql的全文检索。但是由于mysql不支持中文全文检索。所以需要自己对文章进行全文分词的预存储。
第六、由于mysql索引,把常用的索引预读入内存,这样list arc id的时候基本不会产生硬盘io。
第七、不使用typeid2,的可以去掉。上诉几个类的sql有很多可以优化的地方,前提就是多建立冗余数据。只是需要自己回维护数据的同步。mysql5.1.6一上支持触发器。可以自动维护
第八、把不是需要及时更新的比如本日排行,上周点击排行,最新文章等。预先生成html。用第九点的iss包含进入,减少查询次数
第九、优化Apache2,实用iss,将不需要即时更新的数据用shtml方式包含。
第十、相近一切方案降低查询次数,比如arc页面。click查询了一次,如果使用ajax的用户登录判断又查询一次,如果还载入评论,又查询一次,这样是很不合理的。可以修改inc_archives_view.php,一次返回你需要数据。如果你是html方式,那可以修改统计方法一次返回需要数据,再在页面上实用ajax方式读取返回数据更新页面对应区域。一句话,尽可能降低与数据库的交互次数
第十一、文章多了。dede的栏目页面、首页等基本生成不了。你可以增加@set_time_limit(3600);设置,不过这个治标不治本。生成不了的原因是超时,根本原因是由于每一个区域都重复调用arclist,效率太低。你可以参考我之前写的增加sqllist方法,自己些sql来解决。第二,你可以将多个区域使用一个sql来解决。
第十二、dede的分页翻页算法不是很合理,你们可以参考叶子分页(asp)的来修改dede的分页算法。
第十三、dede到最后速度慢的根本原因由于dede_archives表数据量太大。索引不是很合理。click等频繁更新该表,造成缓存使用效率不高。blt可以在新版本中考虑分表。程序分表和数据库分表都可以。一个表的数据不要超过20w条,这样检索效率比较高。大家在现在的版本上的优化方式,复制dede_archives表,每次生成html之后删除,保证复制的dede_archives表数据一直很少。这样生成arc html速度会很快,对于list的生成大家就只能按照前面几点来修正
其实还有很多可以修改和优化的地方,比如实用php缓存。将大文本不如数据库,同时使用sphinx来完成对文件的全文检索等等。
总来的来说。dede的结构还是很不错。只是对于负载、压力这方面考虑相对较少。不过还好,dede开源注释也还比较清晰,可以执行修改。

最后广告一下我的测试站。
测试第三版。争取下月初第四版
第三版和第二版的区别,重写了dede绝大部分核心类,将之前的以生成html提供用户访问的根本出发点,修改成了。list页面和arc页面都是全动态生成。聚合的栏目页面自动更加所属文章更新情况自动更新html。所有不需要实施更新的比如排行等定时自动更新成shtml文件让使用页面包含。页面在考虑效率的前提下尽可能实用ajax降低服务器压力。测试网站问题还很多。大家有什么建议可以给我建议一下。谢谢
ftmouse#163.com #换成@
www.veip.cn

© 版权声明
THE END
喜欢就支持一下吧
点赞10 分享
评论 抢沙发
头像
欢迎您留下宝贵的见解!
提交
头像

昵称

取消
昵称表情代码图片
    • 头像交流负载0
    • 头像交流负载0