主题：【原创】wikipedia架构学习笔记（一）他们的骄傲 -- 羽羊
家园 农历新年之前应该可以填完吧 元旦之前这段时间实在是太忙了，跟飞人似的。。。
pdf文档填坑完成后会同期放出的。
PS：PDF好东西哦，老邓你的东西我做成了PDF，打印出来放在案头有空就看呢，不过要声讨一下几个烂尾坑。。。为了表示愤怒，烂尾坑做的PDF拒绝排版，哈哈，前两天跟子山MM分享了一下，估计那几个没有排版的文档她看的正头疼呢，呵呵罪过罪过。
家园 【原创】大有大的难处——呼叫峨嵋峰~~ 性能调优是个非常头疼的事情，一般而言，很多网站性能出了问题，上来三板斧，第一拆数据库，第二拆应用服务器，第三上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的功能)。
震撼完毕，开始仔细研究这张报表。
好像，发现了一个问题？
您也看出来了吧，这事儿咱们下回接着聊。
家园 没有性能监测就没有性能调优是工程师的基本概念 只有定位了问题才能解决问题。
1，有性能检测或者调试日志。
2，在此技术上的单步跟踪和压力测试。
一般能够解决大量性能问题。
家园 猜猜问题.... fgets吃掉了1/4的时间，说明memcache命中率不佳？
- 复 猜猜问题....
家园 bingo~~ cache ? ,it's a question...
- 复 bingo~~
家园 【原创】长尾和cache 这个是我没弄明白的事情，也是工作中印证的问题。
在CPU的cache机制里面，cache能够起作用，关键在于对代码和数据的访问的locality。说白了就是在未来的一段时间里，有非常大的可能，去访问过去一段时间访问过的代码或者数据。
这个locality和互联网的长尾是根本对立的。长尾是说，这个世界上什么人都有，什么品味都有，有喜欢山珍的，也有喜欢臭豆腐的；有用银餐具的，有吃手抓饭的；最要命的是，喜欢臭豆腐的720个人里面，有两个是把臭豆腐直接吃下去的，有两个是喜欢转1°然后吃，有另外两个是喜欢转2°吃下去...
于是cache就很命苦，刚记下，说客户喜欢转1°吃臭豆腐，接着就要记转2°的，直到最后忘记了，客户过来说：喂，我上次说我喜欢转1°再吃的？
家园 【原创】大有大的难处——先搞定骨干员工 一个企业，骨干员工很重要，一个好的骨干，往往能够带动一个部门，再NB点的，甚至能够形成一种氛围，如果和企业文化能够结合起来，甚至比严酷的制度以及狡诈的激励更有利于管理和生产率的提高。如果骨干员工跟企业对着干，嘿嘿，企业这颗蛋离散黄儿可就不远了。
对于wikipedia来说，mediawiki程序无疑就是它的骨干员工，对于mediawiki，他们没少费功夫。
首先，要清扫外围，把mediawiki有可能消极怠工的借口全部打掉，为防止mediawiki同学拉PHP出来当肉盾，首先部署了APC，apc是个PHP的优化器,会缓存PHP的bytecode，对于提高程序运行速度非常有好处。（对于用PHP做站的朋友，小羊的建议首要就是部署APC，免费，而且效果显著，配置工作量小，而且有完善的监测工具。这玩意儿快有点儿银弹的味道了，好像facebook也在用。）
接下来，wikipedia就开始收拾那些有可能成为性能热区的枝枝蔓蔓：
第一、用Imagemagick替换GD进行图片的处理，GD和ImageMagick相比，首先是功能上面有区别。
GD ImageMagick
GIF No Yes
JPEG Yes Yes
PNG Yes Yes
Cropping Good Good
Scaling Fair Very Good
Rotation Poor Very Good
Flip Good Good
其次，在处理结果，也就是画质上有区别，可以参见
其三，最重要的，性能上有差距，可以参见
关于性能比较，其实还是存在一点争议，有的测试结果指出，使用某些ImageMagick的API，处理速度反倒不如GD，有的测试结果也指出，少量图片的处理GD的速度也比ImageMagick要快，随着图片数量和大小的上升，ImageMagick基本不受影响。但是无论如何，在性能方面，ImageMagick有一个重要的优势：GD作为PHP的一个模块，因为PHP接到请求后初始化资源，响应后释放一切的工作模式，在大负载的情况下，GD无疑会拖慢PHP，反过来说，ImageMagick和PHP完全是松耦合的关系，如果PHP使用命令行调用ImageMagick的话，那么甚至可以说没什么联系。ImageMagick享用OS的资源，给PHP提供服务，如果图片处理成为性能热区，就干脆把imagemagick切出去，然后就一了百了。解耦、然后横向扩展，是大型网站架构设计的一个重要思路。
接下来，对字符串搜索替换开刀，strtr() 是php常用的字符串替换函数，速度其实不慢，但是还是满足不了要求，对于wikipedia这样的网站来说，字符串的搜索替换简直就是一个海量的工作，比如用户编辑内容的格式化、敏感字符包括有安全隐患字符的替换，还有大量的中文繁简体转换，于是他们使用Tim Starling（wikipedia的开发人员和系统管理员）编写的php扩展fast string search 替换掉了strtr()。
这个链接里头还有不少好东西，自己找找看吧
然后，wikipedia是一个用户编纂的百科全书，作为一个使用者，应该认真的研究每个用户提交的修改，毕竟wikipedia声称中立，而用户总有倾向，所以，diff功能是wikipedia使用频度极高的模块，这部分，他们使用了wikidiff作为diff引擎
好了，外围的“皇协军”算是清扫的差不多了，就剩下mediawiki同学老老实实的抱着数据库CRUD，下一步干吗？当然是向八路学习：
安插内线
获取情报
然后……
大刀向鬼子们的头上砍去~
家园 【原创】大有大的难处——硬扛 网站做大了，一台服务器是不够的。
服务器多了，其实真不是好事儿，大有大的难处。
wikipedia的服务器有好几百台，其中web的至少要超过二分之一，这么多的服务器，扑面而来的，不是好处而是问题。
不信？往下看
外链图片需谨慎，可能会被源头改再看看wikipedia的：
外链图片需谨慎，可能会被源头改
外链图片需谨慎，可能会被源头改这里头可以说道说道了。
前一个例子（就叫A网站吧）其实和wikipedia一样，部署了CDN，区别在于wikipedia的CDN有统一的入口，A网站采用了要求用户自行选择的方式，作为一个用户，首先肯定感觉晕菜，作为一个搞web的，个人能理解网站技术人员的难处，同时替他们可惜，这么多镜像站点的维护，本身就足够nb了，可惜万里长征就是不愿意走完最后一步，再花点力气整合一下多好，但是反过来想想，是不是读西厢流泪了？A网站实现wikipedia的模式应该不会有技术上不可逾越的问题，那么这种选择肯定有他们的原因。
挂一漏万的分析一下A网站模式的好处：
1、用户自主选择入口，对于运营商之间存在瓶颈，而且瓶颈本身都不稳定的环境，有必要，至少用户可以多试几次，找到对于自己来说最快的节点。
2、网站的部署简单，只要关注内容的同步即可，甚至某些特殊情况下可以故意造成内容不同步，且不用考虑缓存、反向代理因素，技术复杂度低。
3、如果是商业站点，那么就类似与连锁加盟的模式，在共担投资，分享收益方面责权利清晰。
4、有利于提升用户知识水平。
这些好处当中，第三条和wikipedia半毛钱关系都没有；第四条虽然也是wikipedia立站之本，但好像wikipedia没打算通过行为艺术的方式达到目的；至于第二条，对于一个大网站来说，缓存和反向代理是必要的技术手段，A网站看似规避了这样的问题，但是某一个镜像站点如果压力过大，那么终归还是躲不过去的，难不成到时候再弄个XX镜像2？在这样的技术问题上，wikipedia的性格取向就是“硬扛”，用技术的方法解决技术问题；第一条在某些特殊环境下有效，比如中国内地，但大部分场景并不靠谱，河友就有精彩论断“物理距离近，速度未必快”，原因就在于还存在着诸如镜像服务器负载、机房接入带宽、运营商抽风、奥运开幕、CCTV曝光等等靠用户本身并不能确定的因素。
再看看Wikipedia模式的好处：
1、统一的网站入口，用户体验好。这一点很重要，内容的提取和返回是网站的义务，提升网站性能，还是要 靠 自己。
2、具备内部的负载均衡和健康检查机制，节点负载比较均衡，网站整体性能较好。
3、可以部署统一的缓存或者反向代理方案，进一步提升网站整体性能。缓存和反向代理是个好东西。但是在部署管理方面困难不少，如果非要部署的话，那么还是设计好整体架构，然后一次部署的好，反过来说，镜像网站存在部署N次的风险，wikipedia的模式看似“硬扛”，事实上还是走了捷径。
4、可以把自己的方案综合起来，做个技术网站，或者到会议上做presentation，让人家学习并且景仰。
这样子来说，局外人看起来，还是wikipedia模式好阿。
慢着，这篇两次提到了“硬扛”这个词。
“硬扛” ——状中短语，扛：两手举重物，硬：倔强，执拗地。举重物，还倔强、执拗的，看起来搞wikipedia模式这活儿不轻阿。
其实真不轻。
家园 【原创】外一篇:闲话37signals，rails及其他 web该怎么做？怎么运营？
写wikipedia架构这篇文章的过程中，脑子里总是想着37signals这个公司，这一家公司和wikimedia基金会简直就是两个极端，前者致力于知识传播、和谐社会、世界和平，37signals从一开始就钻到钱眼儿里头坚决不出来（Free is bull****,What's so good about free ? I don't get that,Having 4 million users use your free thing doesn't mean anything. If you charged $1,,you'd probably lose almost all of them,so is it any good at all ？——Jason fried）
，酷吧，让小羊想起了微软关于“用户/客户”的八卦。但是人家赚钱，在geek们看来，却是很少铜臭味道，并且怎么着都透出一股子特立独行的味道，作产品，做出ruby on rails一炮而红，卖服务，捎带着写出一本《getting real》，吸引无数startup.com追捧，公开个人形象都好像美剧剧照——精心装扮、味道十足，西装领带站人家跟前那真是不好意思打招呼，明星人物DHH更是青年才俊，一时风流无限。你说都是做生意，这差距，唉～～～
外链图片需谨慎，可能会被源头改说实话，真不知道该怎么说37signals的架构，和wikipedia不同，wikipedia架构庞大精细严整，透出一股大巧若拙的正规军味道，37signals就显得有些向剑走偏锋的土包子了，跟wikipedia比，真没什么好谈的了。
37signals的王牌产品bashcamp，用rails写成，关于rails，开发的速度毋庸置疑，而性能和伸缩性则一直是非不断，例如和twitter之间那些扯不清的口水官司，至于DHH本人，对于系统架构的看法，颇有些另类：
On the application side and web side, we scale them horizontally. If we want more capacity, we add more application servers, more mongrels, more web servers, etc. On the database side, we're scaling up. We just bought a even bigger box to handle the database for BaseCamp.Basecamp is a pretty big application, have a lot of customers, a lot of usage, but we don't even need to shard yet. As technology moves on, hardware gets cheaper and cheaper. In my mind, you don't want to shard unless you positively have to, sort of a last resort approach.听其言，观其行，再结合rails一些特点：
1、默认适用cookie维持状态，share nothing的一个重要条件。
2、部署推荐fast cgi 或者 mongel cluster，天生适合横向扩展。
3、active record拼装出的SQL， 有些故意的引发N+1问题。
4、多数据库支持，rails核心没有，想要的自己找plugin。
基本上脉络比较清楚了：
1、比较重视程序本身横向扩展的潜力，由于rails框架某种程度上强制程序实现了share nothing架构，所以在加入应用服务器的时候，程序本身不会构成障碍。
2、部署方式无论单台server还是cluster，都是一样的，甚至虚拟机，无非是改改配置文件，加入一个节点就得。
以上两条，决定架构在应用层面都很容易一路横向复制下去，所以rails社区甚至对于ruby本身性能的不满都能容忍下来，反正性能不够，机器来凑。
3、默认ROM拼装出来的SQL都简单至极，从sqlite到oracle都有很好的适应能力，数据量上去了，换更好的dbms都不太用改代码。
4、对于多数据库是漠视的，这样想玩儿shard就比较有难度了。
DBA为什么能拿高薪？sql语句优化，数据库性能调优，shard的维护和管理这些都得拿钱买。rails生成的sql语句基本上都能用的上主键索引，而且语句极其简单，老实说，看不出什么能优化的地方了，如果效率低下了，要么dbms级别太低，要么服务器性能太差，这两条问题都可以很方便的定位，DHH的看法是于其花钱雇人，不如花钱升级服务器，赤裸裸的资本家思维阿。
综上，多么简洁明了的架构阿：
前端nginx或者haproxy或者apache作负载均衡，请求分发到数个分布在N台服务器上的ruby进程或者mongrel服务，然后统一访问一个big ass数据库服务器。
另外，截止07年的数据，5.9 T 用户上传的数据，888 GB 上传文件 (900,000 请求)，2 TB 文件下载 (8,500,000 请求)，到今天应该更多了，37signals更绝，连买硬盘租带宽的钱都抠，人家直接扔到amazon的s3上头去了。最新的消息，原先37signals用了xen做了一部分虚拟化，前些日子人家做了个实验，比较下面两幅图:
外链图片需谨慎，可能会被源头改
外链图片需谨慎，可能会被源头改看起来还是硬碰硬踏实，虚拟化堪忧。
总而言之，这帮家伙真没在性能上费神太多，至少比不上wikipedia花的精力，人家的态度太明确了，挣钱——然后砸钱——然后解决性能问题。
他们的架构师是谁？分明是intel和amd阿。
本帖一共被 1 帖 引用 (帖内工具实现)
又这样的送花党吗？