Discuz! 优化的误区

很多 Discuz! 的用户在论坛规模达到一定程度上,就要经常性的考虑优化的问题。现在网络上的很多热心的技术人都分享了 Discuz! 的优化经验,应该说,很多经验还是不错的,但也有的帖子可能会让用户走入误区。

误区一:SQL 慢,加索引

多数情况下,数据库可能是瓶颈。通过 Slow Query Log 发现执行时间比较长的 SQL 并不难,于是有的人一看 SQL 走了全表扫描,干脆添加个索引好了。

其实这个地方值得商榷的。第一,必须确定一下该 SQL 执行次数到底是怎样的? 执行真的很频繁? 那么对应的页面是否通过 Cache 可以减少对 DB 的冲击? 如果可以,尽量不要添加索引,索引本身对表的负面影响也是很大的,比如降低更新速度,影响并发能力等。

误区二:瓶颈一定在数据库上

前面说,数据库”可能”是瓶颈,但不总是瓶颈,优化的第一步,必需要有针对瓶颈优化。很多时候,图片访问带来的压力甚至比数据库压力还大 — 有的用户数据库、用户上传的图片文件、Web 服务器都扔到一台服务器上,这时候,第一手去调整 MySQL 或许会有作用,但价值不大。

应该说,瓶颈的有效定位的确是个技术活儿,对于一个新的论坛环境,也有人用逐一尝试法来做,这倒也没什么。

误区四:盲目的静态编译 MySQL

静态编译 MySQL 有好处,但如果系统已经在线上运行了,在原有环境中进行静态编译未必能带来多大好处。我问过一些朋友,静态编译到底带来多大好处? 没有几个人能说清楚。

对于 PHP 也是这样,如果一次优化从其它方式上能带来更清晰、直接的开销,就不要重新编译

误区五:反复尝试,但不建立基准数据

这其实是第四点的延伸。而建立基准数据,实在应该是优化的最基本的步骤。这样才能有效的评估优化的效果。否则的话,象误区一描述的,添加了一个索引,短期内可能感觉快了,长期看,性能可能又会慢下来。

误区六:一次进行多个优化步骤

这可能是比较普遍的”习惯”了,有的朋友喜欢一次调整多个参数或是多个环境的设置,然后观察效果。如果每个步骤都是”对”的话,那么效果看起来是好的。如果有的步骤调节”错”的话,可能会抵消那些有效果的优化步骤。

优化策略是个见仁见智的问题。以上只是个人浅见,欢迎留言探讨。

EOF

此文作者:, 位于 Web 分类 标签: , on .
转载须以超链接形式标明文章原始出处和作者信息及版权声明.

13 thoughts on “Discuz! 优化的误区

  1. dongdong

    我们公司最近也在考虑一个优化,目前我们是基于squid的静态cache,所以假如做单篇文章的查询cache (memcache),意义大吗,是增加了应用的复杂度,还是这层cache是否有效

    Reply
  2. Fenng

    @dongdong
    先找出来问题所在,然后再找解决办法
    查询 Cache 用好了当然不错。但这是否能解决问题还是未知数

    Reply
  3. Temple Knight

    “大猫 的评论:
    感觉在建立的时候考虑周全才是最重要的
    事后拆东墙补西墙的…”
    一个项目如果想一开始或者第一阶段就做完美,这个项目失败和流产几乎是定数。

    Reply
  4. virushuo

    这篇不错。
    其实优化是一个方法论的活。首先要有正确的方法和流程,然后才是办法。
    没有基准测试的优化等于白做。很多事情是让A增加10%,让B减少50%。
    我之前那个blog也写过,可惜这种越浅显的道理,大家越觉得无所谓,但是又在不停的重复犯错误。

    Reply
  5. kimi

    Discuz!负载优化还是有很多东西可写的,有空我来写篇。嘎嘎!
    顺带说下Fenng这里的验证码不能刷新。

    Reply

Leave a Reply

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