John Lim 谈到 PHP compilers,列出了目前所知的 PHP 编译器:
但由于 PHP 的很多扩展库都未必适用于其它编译器,所以 mod_php 还是大家的首选。
这是很值得一看的 PDF:Flickr and PHP。文档中对于 Flickr 的架构进行了剖析,下边列出一些重点,以及我们(公司)当前相应的一些应用与个人观点:
- 使用 PHP 实现公共 API 接口,XML-RPC、SOAP 等;(目前我们对于 XML-RPC 运用得比较广泛)
- 使用 Smarty 模板引擎;(我已经开始厌烦 Smarty 的语法了)
- 使用 ImageMagick 处理图片;(这东东真的很好用)
- 使用 MySQL InnoDB,应用 MySQL replication 功能,实现 SELECT 和 INSERT/UPDATE/DELETE 操作分离,分别操作不同的 MySQL 数据库/服务,因为 SELECT 操作远多于 I/U/D 的操作,而 I/U/D 又会阻塞 SELECT 操作;(我们曾经也提出过这样的方案,但需要更多硬件的支持)
- 使用 MySQL MyISAM 的全文检索功能,将 InnoDB 在数据库复制过程中转换成 MyISAM,并使用单独的 MySQL 数据库/服务支持全文检索;(为什么不用 Lucene 呢?)
- 邮件使用 Postfix,由其在接收到邮件之后,将邮件转给 PHP 程序处理;(我们的 WEBMAIL 也是这样做的)
- FTP 服务端使用 Java,接收到上传文件之后交由 PHP 程序处理;(我们用的是 pureftpd 及客户端 FTP 控件,由控件在上传文件完成之后通知某个 URL 的 PHP 程序接棒处理。pureftpd 的方便之处在于可以使用 MySQL 数据库对用户、文件数、空间进行管理)
Flickr 的架构使用 PHP 达到了 90% 左右。目前单纯使用 PHP 实现企业级应用似乎很困难,比如著名的 Ning 也不是纯 PHP 的,有相当一部分的 Java 在支持着,而 Yahoo! 的 PHP 应用则是夹杂了很多 C/C++。有很多方面制约着 PHP 在这方面的发展,比如 PHP 不支持多线程(而这个 Java 等很在行),不适合作为后台守护程序(因为其存在有不少内存泄漏问题,我们曾经为此非常苦恼),对 XML/XPath 的支持不够好,对 Unicode 的支持不够好等等。虽然很多方面 PHP 的后续版本正在改进,但对于一个复杂的企业级应用,也许综合多种语言、技术才是最优方案。
很久没有玩足彩了,突然心血来潮,开始预测一下本期(06012)胜负彩。
伯明翰:桑德兰 3 [1]
布莱克:阿森纳 10
查尔顿:维 拉 0 [1]
切尔西:朴茨茅 3
博尔顿:富勒姆 3
西布朗:米德尔 0 [1]
纽卡斯:埃弗顿 10 [3]
利物浦:曼 城 30 [1]
科 隆:勒 沃 10 [3]
不来梅:门 兴 3
比勒菲:多 特 10
美因兹:凯泽斯 3 [0]
沙尔克:纽伦堡 3
拜 仁:法兰克 3
注:中括号里的为附加预测结果,因为¥的原因,所以放弃了。
之前足彩从来没中过,可能是由于自己太过于保守了,思维过于常规化,想要赢得足彩大奖,没有冷门是不行的,而英超的冷门似乎更多一些,德甲好像不怎么爆冷,所以这次大胆的预测了曼城可能爆冷胜出,而切尔西在连续郁闷之后该开始振作了,主场全取 3 分问题不大。
也许有不少朋友已经注意到在我的 BLOG 页面右上方多了个蓝色块及桔红色图标,这是由 FeedBurner 所提供的 RSS 订阅服务,可以通过点击这两个图片,进入订阅页面,在订阅页面中选择 Yahoo!、BlogLines、Google 等等。其实我使用这项服务是希望能够借此了解到底有多少朋友订阅了我的 BLOG FEED,也是想知道有多少人读我所写的这些胡言蜚语

来自 snook.ca,为了更好地了解 Prototype,作者画了几张剖析图,确实可以让人一目了然
