Discuz! 优化的误区

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

误区一：SQL 慢，加索引

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

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

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

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

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

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

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

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

误区五：反复尝试，但不建立基准数据

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

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

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

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

–EOF–

谨慎对待自我生成内容(egc)

标题里的 egc 代表：ego-Generated Content，是我模仿 UGC(User-generated content)造出来的一个词。用以表示个人生成内容，尤其是在一些 UGC 网站产生的内容。

记得 CSDN 的曾登高问过我：

如果 CSDN 开发一个 Google Group的功能，你会创建自己的小组，建立一个兴趣小圈子吗?

我的直接回答是”不用”，尤其是国内的很多明显是克隆国外服务的站点，比如饭否这样的。最近一段时间里，一觉醒来，似乎遍地都是 SNS ，对于一些明显是浑水摸鱼的服务，我一般会敬而远之，即使注册了，也基本不会真的花费心思去参与。原因只有一个：自己生成的内容是有价值的，有价值的东西不要随便扔到不靠谱的地方，当然，这么说肯定会引起一部分人的误解(我现在也在用个别的 SNS 服务，主要的目的还是为了研究用户体验和产品设计。作为一个技术人员，至少到到现在为止，还没从 SNS 服务里面发现比较有价值的技术内容)。

自我生成内容成本其实很高。考虑到每个人的一生也就那么长的时间，如果你的时间有价值，那么产生的哪怕每个字符都有必要保存，一旦内容丢失，对个人来说，就是最大的浪费。我个人不认为 SNS 之类的服务能产生更有价值的信息，倒是有可能产生更有价值的”关系“，而且，SNS 的服务很少让人静下新来作一些”沉淀”，每天被新信息充斥着。

至于 LifeSteam：之所以会产生 Lifestream 功能的服务，其终极目的还是要把一个人产生的内容融合起来，但这里面最大的一个问题是，不能做信息的归档保存(类似数据库-> 数据仓库的机制)，只是即时更新的信息流而已。从这一上来说，也不利于 egc 的整理。

所以，有必要谨慎对待自我产生的内容，尽管你还没发现这些内容的价值。也不要趋之若鹜的去到处尝试一些新服务，做小白鼠其实没什么大价值。

个人建议：

同类服务只用一个，最多用两个，如果用了三个，那么你是一个义务测试员。

–EOF–

《赤壁》–战争片中的喜剧片

周日上午在上海，宾馆里的电视放着在成都举办的电影《赤壁》首映礼，听着到场明星如潮的谄评，我开玩笑说，”没准是个大烂片”，没错，说中了。

有《三国志》也没用

和《三国演义》不相符的地方，吴宇森可以说是研究《三国志》得来的，和《三国志》不一样的，可以说是遵循《三国演义》。可几个人面对着一匹难产的马折腾了半天，这是跟什么地方学来的? 《英雄本色》么? 这样多余的段落实在太多了，听牧童吹笛、孙权射老虎(这段是给外国人看的，建议海外版把这一段加进去，很弗洛伊德）、古代足球–蹴鞠等完全是可有可无的桥段，没有这些，冲着当年吴宇森拍过的片子，大部分观众可能也愿意掏钱的。

人物形象

冷兵器变成了现代武打，下次让关羽骑马吧，每次跑着出来(当然是穿着刘备给打的草鞋)，拖着大片刀也的确不太好；张飞也最好带着兵器，别总赤手空拳，好像把丈八蛇矛弄丢了似的，这样不好! 至于小乔，那双手也太大了些，特写太多了些；周瑜的头盔实在有些不好看，建议和《投名状》学一下嘛，反正都是古装，穿越一下就成了。至于瑜亮的大段飈琴，简直是现代摇滚青年的翻版嘛。

吹毛求疵

刘备自称的”豫州”也实在让人倒胃口，哪有这么说的? 而八卦阵那一段，估计连外国人也糊弄不了吧? 孙子兵法都说了，”十则围之”，对付区区两千敌军还折腾半天。

那些笑声

搞笑的亮点有很多：刘备要诸葛亮多吃米饭，刘备重拾本行打草鞋，诸葛亮在孙权殿前走起的模特步，关羽给孩子们上课居然说出”现在读书，以后就会有饭吃”，而张飞聚精会神练习书法(尽管张飞历史上的确是书法家，可剧中人物那握笔的姿势实在有些问题嘛)，听着一次又一次的笑声，完全有理由相信这是吴导演的转型喜剧之作。

估计很多人会疑问，这就是那个拍出《英雄本色》的吴宇森么? 现在开始怀念那“一亿颗子弹”吧，然后，面对着下集可能出现更多的恶评，吴导演最需要的是”冷静”。

–EOF–

比较出彩的地方，应该算曹操的 “架六龙，乘风而行；九合诸侯，一匡天下” 那个镜头。这句话是从曹操的两首诗里面拼出来的。

上海两天之行参加技术沙龙

上周六去了上海，参加博客大巴 CTO 车东组织的 Startup 技术沙龙。

杭州这几天很热，我的 ForecastFox 插件上显示的是根~~小火柴~~温度计(?)：。下午 4 点多的时候和同事 Ningoo 一起出发，到了杭州火车站发现人真叫一个多啊。让我稍感到安慰的是和谐号车内空气质量似乎比以前好多了。一路顺利到了上海，居然都没晕车。

要出行，找携程

出于节约成本的考虑，星级酒店不能住啦。出发之前，给汉庭打了订房电话，为保险起见，给另外一家快捷酒店的”旗舰店”也打了电话。出火车站后电话询问汉庭的位置，如论如何也听不清楚电话里那个家伙说的话，只好先去另一家”旗舰店”，手续敲定，进了房间，一股霉味扑鼻而来，二话不说，下楼退房跑路，再给汉庭打电话，这次终于弄明白具体的位置了，赶过去，前台告诉我，房间取消了。”因为你是散客订的房，所以，时间到了就取消了”，接待人员牛气的不得了，爱理不理的样子。

只好重新订房。Ningoo 说自己是携程金卡会员，给携程打了个电话，等，不一会儿电话回来，房间定好了，上航假日酒店，价格也不贵，到了一看，性价比很高。我不由得赞不绝口。这里严重表扬一下携程，想方设法给用户省钱的公司就该赚钱，携程的价值或许低估了许多。

当天晚上，昔日的魔岩三杰也在上海开演唱会。

参会感受

BlogBus 位于 2577 创意大院，很休闲，都有些不太像 IT 公司，还养了一只狗，后来我临走的时候差点咬我 :)

参加讨论的朋友们陆陆续续到场，没有什么偏商务的宣传，话题都是大家平时遇到的一些技术点，现场气氛很好。参会的朋友来自 Blogbus、51、安居客、CDN Union、豆瓣、虾米、5173 等众多网站的朋友，我和另外一位周日上午赶到的同事（搜索引擎专家)代表支付宝，Ningoo 则来自淘宝。

信息不对称还是比较严重的，尽管有些技术问题可能是类似，但解决的办法和思路还是能互相带来很好的参考和借鉴。记得马云说过，”技术只有分享才有进步”，的确如此。会上主要议题包括：LifeStream 产品设计思路、数据库备份策略、日志处理、防 DDos 攻击等。因为还有些东西也涉及到业务数据，不多说了。

我在会上的一个技术论点：关于 Cache 服务器数量的问题，当时的说法：尽量保持为 2 的 N 次方。回来仔细想了一下，多少有些武断了。这个问题我回头仔细思考一下。这个思路用在 Sharding 上似乎没问题，但是是否能扩展开来? 未必站得住脚。

又看到老朋友，结识了新朋友。这也是大老远跑来才能收获到的吧。

归程

回来的路上挺有意思，三个人一路赶到上海南站才发现车票……居然是上海站的，三个人一口差点一起晕倒。匆忙坐地铁过去，地铁上发现一件有趣的事儿，所有的液晶屏终端都是 Linux 操作系统，而且在不停的重启动…

128M 内存，Linux 2.4 Kernel 的 :)

–EOF–