【老文转载】PHP框架的繁荣是正确的发展方向吗?

【老文转载】PHP框架的繁荣是正确的发展方向吗?

PHP和Python/Ruby的运行机制有一个本质区别:PHP是每次HTTP请求过来以后,初始化全部资源(例如创建数据库链接、加载系统类库,创建缓存等等),处理完毕,释放全部资源,这不像Python/Ruby之类带有GC的脚本语言,Python/Ruby是初次启动的时候初始化资源,随后的请求就不必再次初始化资源了。

这种机制的差异带来的区别就是:

1、PHP极难出现严重的内存泄露问题,随便你代码写的多烂,反正每个请求一执行完毕,所有资源统统释放光。而Python/Ruby则需要依赖GC来回收内存,因此稍有不慎,还是会出现GC无法释放的内存泄露问题。

2、PHP每次请求都要初始化资源,这个开销非常大。所以尽管PHP解析器本身的运行速度是极快的,但是一旦使用复杂的PHP框架,那么由于需要每次请求的时候初始化整个框架,性能的下降非常厉害,你用一个很复杂的PHP框架的结果就是整体性能被Ruby远远甩开。这也是为什么PHP社区这么多年来,并不怎么倾向于使用框架的原因之一。

3、由于PHP这种每请求初始化资源的机制,也造成了PHP添加跨请求的高级特性相当困难,这是PHP本身一个很大的限制,但是反过来说,正是这种限制使得PHP始终保持在一个比较简单的web语言上面,而正是这一点才是PHP得以成为互联网第一Web编程语言的原因,因此也未必就不好。

总之,PHP和Ruby的差异还是很大的,不适合放在一起比较,其实应该比较的是Ruby和Python才对。

所以我觉得Rails这种框架性做法被PHP跟风以后,其实是把PHP带上了邪路,所以不如说是Rails在误导PHP的发展。顺便多说一句:DHH在编写basecamp之前,一直是用PHP的,并且自己还写了一个PHP的快速开发框架,他改用ruby以后,把当初自己写的PHP框架也移植过来了,这个框架实际上是Rails最初的原型。那么为什么DHH当初不直接基于PHP做Rails呢?非要改用ruby以后,才发表rails呢?你看看PHP这种运行机制就知道了,PHP做复杂的web开发框架并不是一条光明的道路。

 

http://www.iteye.com/news/4341-rails-and-merb-simple-performance-test

这条JavaEye新闻里面有简单的性能测试,CakePHP可以用惨不忍睹来形容。

http://www.bloggern.com/3836.html

左轻候写的PHP沉思录里面有对PHP运行机制的详细分析,以及对于Drupal性能分析,他写这篇博客的时候,我们在msn上面对PHP和ruby的运行机制讨论了很多。

以PHP这种“每次请求作为一个完整的生命周期”的语言来说,本身就是追求简单、反框架的。大型PHP互联网应用会在后台用Java/C++写中间件来完成复杂的业务逻辑处理。非要把PHP做成框架,并不是PHP本来应该承担的责任。

 

 

PHP不同框架的性能差别很大

我有一个应用,先开始图简单,用的Zendframework,pv 200k以下问题倒还不大,就是cpu高点,到了pv 400k的时候就有问题了,并发稍微高一点,就会占用大量的系统资源,系统连64个并发php-cgi都没法支撑。

最开始以为是应用架构或代码有问题,因为这个应用也确实有些特殊,有一个2、3个小时高并发读/写阶段,并且每个写请求会带来10M左右的磁盘写io。最开始认为问题在这里。

但是就在我打算用django/python重写这个应用之前的一刹那,抱着试一试的态度,换了一个php的framework:codeigniter,只是把action部分重新调整了一下,核心应用的业务逻辑完全没有变化,然后部署尝试。整个系统的负载较之以前降低10倍可能都不止。

现在虽然流量变化不大,但是整个网站完全不会看到cpu耗尽的情况,io/内存都不是问题。由此可见,php的框架之间确实存在很大差异,需要慎重选择。

另外,CodeIgniter其实也就是一个够用的框架,功能其实很简单。也正是因为简单,所以性能才高。

其实对于php来讲,PDO已经是不错的ORMapping层,所以选择框架实际上是在选Routing和action的组织,其他的完全没有必要弄得太复杂。

 

站在产品的层面来看,Python的CMS plone是最优秀的,功能非常强大,二次开发很容易,又没有drupal的性能问题。上海润普就用plone开发了好几个商业项目了,其中包括像上航的一些系统。

但问题是:即便在Python社区里面,高度产品化的zope/plone现在也渐渐不再是主流了,主流技术跑到了django那里去了。所以drupal这种反PHP理念的东西能有多大前途,我觉得很难说。

其实PHP核心问题都不是性能,而是能不能保持“简单性”和“草根性”

一个有点编程背景的普通人,只需要学习PHP半天时间,就可以上手开始开发web应用了,这就是PHP最大的优势。专业程序群体才多大,而电脑爱好者的群体有多大? 我一个朋友,做photoshop出身的,人家学了两天PHP,到处接活给人家开发网站,一个人全部搞定。你让他学Java,那真要了他的命了。我另外一个朋友的老公,人家压根就不是这一行的,照样会用PHP搭网站,人家上网去下载一个PHP程序,改吧改吧页面,就弄好了,你让人家学ruby?那肯定不可能。

PHP的人海战术也就是这么来的,群众基础好。事实上PHP5曾经在相当长时间内被抵制,就是因为PHP5的面向对象语法引入了对于电脑爱好者来说门槛开始变高了,PHP开始变复杂了。

因此PHP再用什么框架,是违背PHP本身的设计哲学的。PHP就应该做简单的页面处理就够了,复杂的逻辑让后台的Java/C++去处理。

 

zope2/plone 还是一个产品化的东西,还是比较易用的,通过  product 也可以扩展,但是后来发展起来的 Zope3 就是相当复杂了,其复杂性可以和整个 J2ee 相比较,跟 zope2 根本就是两回事,真是“没有接口创造接口也要上”,简直就是 java 程序员的作品,最终闹的 java 这边没人喜欢, python 那边也没人喜欢,pyhton 程序员还是比较喜欢简单的东西的。

简单的来说:
PHP 就是: Quick and Dirty
Java 就是: Beauty and Slowly
Ruby 就是: Quick and Beauty
python 就是: Quick and Simple

 

既然提到我了, 这个我要澄清一下!

第一、ruby的内存分配机制尽管比较粗鄙,但是没有想象当中那么差劲。

其实现在互联网行业当中,使用ruby的大规模应用比比皆是,twitter,37signals,Engine Yard,包括Amazon的一些东西。所以ruby做互联网应用从GC的角度来说,是肯定没有问题的。

第二、JavaEye的确有一个监控ruby进程的脚本,但最后证实内存泄漏并非ruby引起的

JavaEye曾经出现ruby进程总是内存泄漏的现象,我曾经认为是ruby的GC造成的。但是后来我用了一个巧妙的办法,就是这个:监视Rails进程内存泄漏的技巧,找到了内存泄漏的罪魁祸首。真正的原因是我们有几个处理大数据量的代码犯了愚蠢的错误造成的,具体是什么愚蠢的错误,就不足为外人道也了。

尽管由于幽灵指针造成的ruby存在轻微的内存泄漏,但事实上除非你用ruby做后台服务,长期不间断运行,否则这个问题并不会影响到你,特别是Raisl应用来说,基本上不会受影响。

当然我很乐见MBARI补丁现在正在被合并到ruby 1.8.7的trunk上面去。只不过这个补丁现在存在一个怪异的不定期出现的CJK编码转换的兼容性问题,我正在进行大数据量中文编码转换的测试,以寻求能够重现该错误,并且尽早提交这个issue。否则等下一个ruby 1.8.7 patch level版本正式发布以后,倒霉的就是我们中国的Rails用户了。

第三、Java的GC应该是目前最成熟的虚拟机GC实现了。否则也不会出现jruby项目。但是虚拟机成熟不代表在所有的应用领域都很成熟。在Web开发框架方面,Java确实很令人失望。

 

这本来是一个探讨PHP框架和Rails的话题,怎么又跑题到Java vs Ruby上去了? 跑题的家伙自己出来自首吧。

如果说语言的比较和借鉴是一个挺有意思的话题的话,那么搞xx PK xx就很无聊了。我们JavaEye网站实际上同时用到了Ruby,Java和PHP三种编程语言:Ruby用来做Web层,Java用来实现后台的全文检索服务器,而PHP用来实现邮件列表和邮件群发功能。所以我爱ruby,但是我也爱Java和PHP,如果将来JavaEye又用上了Python,你也不要吃惊,编程语言就是工具,工具是被你使用和玩的,而不是控制和玩你的。。。。。
http://www.iteye.com/topic/319039

发表评论

电子邮件地址不会被公开。 必填项已用*标注