主题：【原创】wikipedia架构学习笔记（一）他们的骄傲 -- 羽羊

性能调优是个非常头疼的事情，一般而言，很多网站性能出了问题，上来三板斧，第一拆数据库，第二拆应用服务器，第三上memcached，这三招使出来，问题往往会消停一段时间，但不过是饮鸩止渴而已，这三招，基本涵盖了有可能出现问题的方方面面，在不清楚性能问题症结的情况下，这种全方位火力覆盖的方法规避而不是真正解决了问题，拆拆补补总有个限度，一旦性能再次恶化，就很难收拾。

在两眼一抹黑的情况下，没有办法精准的定位问题所在，仅仅是不停的三板斧耍下去，实际上是在不停的增加复杂度，因为三板斧本身也是两眼一抹黑的，这样，早晚有一天，整个架构，会被自己的复杂度压垮，这样的例子很多。所以，做网站的性能优化，首先要在profiling上做好足够的功课，首先要明确哪些地方用的多，然后还要弄清楚哪些地方跑得最慢，换句话说，要在庞大的网站黑箱里头掺沙子，安插余则成上报敌方动向，否则，hoho，要不然就是狗咬刺猬，要不然就是费了牛劲优化的是一个十年也用不上的地方，另一方面，一个慢速的socket连接正在逐渐的把网站性能拖向深渊。

Wikipedia的余则成在哪里呢？

mediawiki程序主要的代码段调用了profiling函数wfProfileIn和wiProfileOut，（函数代码在include/profiler.php文件中，另外还有5个profile开头的php文件，也负责profile工作。恐怕以某些OOfans的眼光来看，代码写的不算漂亮，这有php自身的原因，但简洁实用），这两个函数会把性能数据存入数据库或者发给一个监听3188端口的后台守护进程（守护进程的代码在外链出处），这个守护进程会形成一个实时的性能数据报告。，我们跳过无聊的代码分析，直接看看生成的报告

外链出处，

有了这样的报表，程序性能热区在什么地方，一目了然。

一个哥们儿说过，开源的世界里，好东西的多少，仅仅取决于我们的视野，诚哉斯言。即使面对上图这样的性能报表，wikipedia仍然不满足，于是我们在他们的指引下，又见识到了一颗闪耀的珍珠-kcachegrind，外链出处，这是一个性能数据的可视化工具，能够输出可读性非常好的性能数据报表。

到此为止，有了meidawiki程序内部的余则成，还有了监听3811端口的联络站，最后还有 kcachegrind坐镇特科情报分析中心，wikipedia这一套组合拳打出，性能问题门户洞开，只等兵临城下、一战成功了。

面对这样的性能监测结果，小羊首先感觉到的是震撼，从wikipedia的profiling动作中，体会如下：

1、没有性能监测就没有性能调优

2、性能监测要从代码抓起

3、监测结果要充分的可视化以便分析

4、监测功能要简洁快速，免得自身的负载干扰监测结果，同时要有灵活的开启和关闭能力(mediawiki程序当中的startprofile.php文件提供了关闭profile的功能)。

震撼完毕，开始仔细研究这张报表。

好像，发现了一个问题？

您也看出来了吧，这事儿咱们下回接着聊。