西西河

主题:【原创】wikipedia架构学习笔记(一)他们的骄傲 -- 羽羊

共:💬62 🌺262
全看分页树展 · 主题 跟帖
家园 【原创】大有大的难处——呼叫峨嵋峰~~

性能调优是个非常头疼的事情,一般而言,很多网站性能出了问题,上来三板斧,第一拆数据库,第二拆应用服务器,第三上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的功能)。

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

好像,发现了一个问题?

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

全看分页树展 · 主题 跟帖


有趣有益,互惠互利;开阔视野,博采众长。
虚拟的网络,真实的人。天南地北客,相逢皆朋友

Copyright © cchere 西西河