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

一个企业，骨干员工很重要，一个好的骨干，往往能够带动一个部门，再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

其次，在处理结果，也就是画质上有区别，可以参见

GD1 GD2 Imagemagick缩图画质比较

其三，最重要的，性能上有差距，可以参见

GD imagemagick缩图速度比较

关于性能比较，其实还是存在一点争议，有的测试结果指出，使用某些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()。

Fast string search

这个链接里头还有不少好东西，自己找找看吧

然后，wikipedia是一个用户编纂的百科全书，作为一个使用者，应该认真的研究每个用户提交的修改，毕竟wikipedia声称中立，而用户总有倾向，所以，diff功能是wikipedia使用频度极高的模块，这部分，他们使用了wikidiff作为diff引擎

好了，外围的“皇协军”算是清扫的差不多了，就剩下mediawiki同学老老实实的抱着数据库CRUD，下一步干吗？当然是向八路学习：

安插内线

获取情报

然后……

大刀向鬼子们的头上砍去~