|
该帖已经被评为精华帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2009-01-20
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本来应该承担的责任。 |
| 返回顶楼 | |
|
发表时间：2009-01-20
最后修改：2009-01-20
Drupal好不好， 就要看你能了不了解他了
不过性能是一个问题（就如robbin所说的那样， 每次都要执行所有的代码， 所以可能模块越多， hook函数越多就越慢）， 模块化是一个优点， 可惜不是SCA标准， 这个是比较讨厌的。 后台管理和前台展示不能分开等（代码不是很好管理， 这个也是挺不爽的， 看看JAVA才发现， 其实真的很优雅）。 ---------------------------------------------------------------- 不过从其它方便面来看PHP和Drupal， Drupal只要有人给你讲两到三小时， 你就能上手开发了， PHP只要你认真看它2小时语法（而且还是一点没有PHP知识的）， 你就大概能开发网页了。 Drupal的异常强大（可订制， 超多可用开源模块） 会让你事到功倍 （如果叫你去开发那些东西， 会弄死你的）。 没有比这个更快上手的， 所以很适合快速网站开发。 RUBY在这里就体验出成本的劣势. |
| 返回顶楼 | |
|
发表时间：2009-01-20
xiaoyu 写道 Drupal好不好， 就要看你能了不了解他了
不过性能是一个问题（就如robbin所说的那样， 每次都要执行所有的代码， 所以可能模块越多， hook函数越多就越慢）， 模块化是一个优点， 可惜不是SCA标准， 这个是比较讨厌的。 后台管理和前台展示不能分开等（代码不是很好管理， 这个也是挺不爽的， 看看JAVA才发现， 其实真的很优雅）。 ---------------------------------------------------------------- 不过从其它方便面来看PHP和Drupal， Drupal只要有人给你讲两到三小时， 你就能上手开发了， PHP只要你认真看它2小时语法（而且还是一点没有PHP知识的）， 你就大概能开发网页了。 Drupal的异常强大（可订制， 超多可用开源模块） 会让你事到功倍 （如果叫你去开发那些东西， 会弄死你的）。 没有比这个更快上手的， 所以很适合快速网站开发。 RUBY在这里就体验出成本的劣势. 你说的也很有道理. 老美的确很倾向于能用Drupal就用它. 但我同样认为Drupal基本已经可以算"产品", 比框架层次更高. 所以这样和rails比是有点不公平的. 但这的确又是现实, 看来rails真的还缺乏这样优秀的"开源产品"啊. 幸好这个项目客户已经排除掉了Drupal,因为定制性比较高. Drupal不能满足需求. |
| 返回顶楼 | |
|
发表时间：2009-01-20
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的组织，其他的完全没有必要弄得太复杂。 |
| 返回顶楼 | |
|
发表时间：2009-01-20
站在产品的层面来看，Python的CMS plone是最优秀的，功能非常强大，二次开发很容易，又没有drupal的性能问题。上海润普就用plone开发了好几个商业项目了，其中包括像上航的一些系统。
但问题是:即便在Python社区里面，高度产品化的zope/plone现在也渐渐不再是主流了，主流技术跑到了django那里去了。所以drupal这种反PHP理念的东西能有多大前途，我觉得很难说。 |
| 返回顶楼 | |
|
发表时间：2009-01-20
我最喜欢的IT音频博客网站Twit 就是用 Drupal 建立的，那个创始人 LEO 碰到嘉宾就说 Drupal 好话。
|
| 返回顶楼 | |
|
发表时间：2009-01-20
不知道上面的测试是cakephp 1.2 final还是rc版。
在我的印象中，ci应该是php框架中运行速度最快的，cakephp其次,symfony最后。 php使用框架，除了做快速开发，也有易于维护的，便于移植的因素在里面。 个人的想法是，开发什么样的应用，就可以考虑什么样的技术，没有一个技术是通用的，关键要看是否适合要开发的项目，如果只是开发最简单的应用，我倒觉得直接写php代码最快，上什么框架都是累赘，但是又不可能所有的项目都如此，所以才会涌现如此多的框架和技术。按需索求才是关键。 |
| 返回顶楼 | |
|
发表时间：2009-01-20
magician 写道 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的组织，其他的完全没有必要弄得太复杂。 之前看过codeigniter，并且写过一些代码，与ZF相比，这个框架是非常轻量级的。 有点不明白为什么Zend官方要搞这么一个庞然大物ZF。 我觉得PHP最致命的一点是没有一个可用的ORM。如果一个熟悉了hibernate或activerecord这种ORM的程序员去搞PHP，会有一种郁闷的感觉。 |
| 返回顶楼 | |
|
发表时间：2009-01-20
fnet 写道 magician 写道 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的组织，其他的完全没有必要弄得太复杂。 之前看过codeigniter，并且写过一些代码，与ZF相比，这个框架是非常轻量级的。 有点不明白为什么Zend官方要搞这么一个庞然大物ZF。 我觉得PHP最致命的一点是没有一个可用的ORM。如果一个熟悉了hibernate或activerecord这种ORM的程序员去搞PHP，会有一种郁闷的感觉。 有的有的...而且别人也叫activerecord... (http://qeephp.com/bbs/viewthread.php?tid=5582&highlight=active%2Brecord) 这点根本不是php致命的地方... 我觉得Robbin谈到的性能算一个.... 还有其他的吗? |
| 返回顶楼 | |
|
发表时间：2009-01-20
robbin 写道 站在产品的层面来看，Python的CMS plone是最优秀的，功能非常强大，二次开发很容易，又没有drupal的性能问题。上海润普就用plone开发了好几个商业项目了，其中包括像上航的一些系统。
但问题是:即便在Python社区里面，高度产品化的zope/plone现在也渐渐不再是主流了，主流技术跑到了django那里去了。所以drupal这种反PHP理念的东西能有多大前途，我觉得很难说。 Robbin能不能谈谈, 高度产品化的zope/plone的"失败", 是因为zope/plone本身的"失败"? 还是"高度产品化"的失败? 很想听听你对这方面的看法. 因为我猜测也许rails社区也会出现这种"高度产品化"的东西. |
| 返回顶楼 | |
