PHP框架的繁荣是正确的发展方向吗？

各位且慢下结论，我记得PHP明明也是支持FastCGI或者类似FastCGI的结构呀！
按照一般的理解，语言结构上也许PHP没有那么动态强力，但基本语言的性能上，PHP应该跟其他脚本语言是一样水平的？只会更快不会更慢才对？
如果ROR用普通PHP的模式执行，一秒钟请求数目搞不好只有两位数一位数，如果PHP用FastCGI的模式执行，按照随手Google到的来看，复杂处理每秒钟700个请求是没问题的？
用FastCGI模式的ROR和普通PHP模式的QeePHP比较，本身就不公平吧？
dualface你费时花费那么多口水去吵这些，自己做一个性能测试大家不就都清楚了么？大家都上FastCGI，看看ROR,CAKEPHP,你的QEEPHP在同等架构下到底效率怎样。
PS.我记得第八主机是提供FastCGI模式的PHP虚拟主机的。

综合大家的金口玉言，学习了不少东西，整理点相关资料，收藏备查：

1.一个支持PHP的数据库连接池项目SQL Relay
http://koda.iteye.com/blog/320911

2.PHP的数据库永久连接
http://koda.iteye.com/blog/320909

3.理解FastCGI应用的性能
http://koda.iteye.com/blog/320880

4.FastCGI 不完全高级指南（PHP版，Windows平台）
http://koda.iteye.com/blog/320873

PHP跑FastCGI方式，并不会比Apach Module方式有数量级的性能提升。这是因为：

1、PHP解释器本身bootstrap速度非常快，开销很小（在不使用PHP框架的情况下）

2、PHP是“每请求生命周期”的运行模式，采用FastCGI这种进程常驻内存持续运行的方式，并没有特别的性能提升作用。

天，这个生命周期是完全封闭的么？那样的话还真没辙了，语言不管怎样增强和动态都白搭了。
我一直以为脚本语言载入一堆context然后挂着等你请求是理所当然的。按理说，语言的部分只要一个php语法解释器就好，生命周期之类，就不能开放出来么？

是处理完一个就转为空闲状态，如果有新请求，就处理下一个。并不是一个进程同时处理很多个。

我就一并回答了

从语言实现的执行效率上看，PHP 比 Ruby 快。不过应用程序的实际性能表现并不是光靠语言本身就能决定的，比如 ruby 现在有多线程、纤程，使用得当的话，对性能有很大帮助。

-----

单纯从一个请求看，用 mod_php 在 Apache 里面跑 PHP 和用 lighttpd 跑 PHP 确实性能差异不大（虽然 FastCGI 模式肯定更快）。但是由于 Apache 的 mod_php 应付高并发请求比较困难，而且 Apache 本身也不快，所以流行的 lighttpd/nginx + fastcgi + php 模式在高并发时可以获得更好的性能表现。这就是为什么大家用 fastcgi 跑 php 感觉比 mod_php 快很多的根本原因。

至于 php 开发框架，其实只要设计合理，bootstrap 的开销也很小，通常也就是载入两三个文件。而所有的配置文件都可以预先解析为 php 数组后输出为 .php 文件，运行时直接 include 就行了。

实际上即便你不用 php 开发框架，很多 bootstrap 工作也是要做的。比如检查请求参数、载入配置等等。而 php 框架可以设计为“按需加载”来进一步减小 bootstrap 的开销。比如本次请求没有用到数据库操作，那么根本就不会载入数据库相关的文件，也不会使用数据库连接。

-----

与其他语言开发框架的性能测试我肯定要做的，只是现阶段主要精力还在完善文档上。目前只是简单（Windows 环境的 Apache mod_php）测试了一下 QeePHP 和 Yii 的性能比较（Yii 是一个国外的 PHP 框架，性能比 Code Igniter 快上几倍，Yii 自己的测试报告 http://www.yiiframework.com/performance/），QeePHP 要比 Yii 高一点。

从 yii 的测试看，yii 大概是 ci 性能的三倍，而 http://www.iteye.com/news/4341-rails-and-merb-simple-performance-test 里面，ci 的三倍性能已经超过 rails 2.2 了。当然这样的比较并不严谨，不过参考一下还是可以的。希望以后可以在大家的帮助下通过严格的性能测试来得出确切的答案。

其实 PHP 的运行模式有很多优点：

1、简单，因为没有进程间通讯、多线程等东西，应用程序的模型变得很简单
2、稳定可靠，几乎不需要关心内存泄漏问题
3、高性能

当然，因为 PHP 应用程序不能持续运行在 PHP 进程中，处理一些需求时会有点麻烦。而且因为没有多线程等功能，实现后台任务也不方便。但是比较而言，我认为 PHP 这种运行模式的好处比坏处多。

1.SQL Relay是连接池，但不是PHP实现的（这半句不是对你说的）。

2.永久连接和普通连接还是有功能上的差异的，而连接池中的连接和普通连接没有太大的区别，根据永久连接的策略来说，永久连接也只是部分缓解了重复建立数据库连接的问题，理论上来讲，效率和可管理性是不如真正的连接池的。

哦，如果有人要跳出来说PHP连接mysql建立连接开销很小的话，就另开一个话题吧。

没错，SQL Relay支持php客户端而已。虽然给出一些相关资料，但是我自己在PHP中却不使用连接池，且不说连接效率如何，而是增加管理复杂度，如果什么框架都上，宁可选择Java。使用php也是保持简单性，尽可能在Cache和静态化角度满足应用性能。

就不引用全面了，首先我勇于接受PHP的OO，努力从菜鸟转变成一个老鸟，非常支持使用框架，但是要根据自己的应用适当使用。这个考量的标准的就是：基于我的应用，考察备选框架是性能指标。

接下来说的不知算不算跑题，这个问题就是：为什么大部分PHP框架都不如其他语言的快，难道每一个框架都像你说的是实现问题？如果Qee真的能成为典范，我一定第一时间使用。
另外，PHP到底能应付多大复杂度的框架、平台，特别是像Magento,Drupal这种伸缩性极强的平台（性能上让人不太满意），如果就是要实现这样的平台，你觉得你可能用PHP实现一个性能上绰绰有余的同类产品吗？
我希望你回答的是基本可能:)，否则那就是说：对于某些web平台产品，PHP语言本身出现了瓶颈！！


当然，左右我选择一个语言和框架的因素可能包括：Scaling,Dev Speed,Dev Tool, Matainability

参照 http://www.cmswire.com/cms/industry-news/php-vs-java-vs-ruby-000887.php