基准测试的问题在于，它们通常不适用于真实的世界。编写一个真实的应用程序，你会发现所有的框架在速度上都相差不大。而且它们都比你不使用框架（并且知道如何编程）的情况要慢。
然而，你需要考虑的是权衡。框架牺牲了一点性能来显著减少开发时间。对你来说，哪一个更重要，原始的性能还是合理的快速开发时间？Facebook不会为他们的网站使用RAD框架，但这是因为对他们来说，性能比增加的开发时间更有价值。同样，一个只有一个开发人员的小公司从框架中受益可能比合理的小的性能损失（我说小，是因为对每个页面的影响是最小的。这种影响随着更高的流量而“累加”）更大。
我的建议是，浏览一堆框架，尝试一下（大多数都有一个“博客”教程）。感受一下它们是如何工作的。挑选一个你喜欢的，然后用它玩一小会儿。了解它的编码风格，以及它喜欢如何做事情...最重要的是，学习它是如何运作的。试着学习细节背后的“为什么”。使用框架的能力与理解它是如何运作的直接联系在一起......除非万不得已，否则不要使用你不舒服的东西。找到一个“适合”你的，然后坚持下去，直到你流利...

我推荐cakePHP v1.3，因为它更快，更容易理解。你会找到与这个框架相关的非常好的帮助（文档和教程）。文档写得很好。即使你被困在某个地方，你也能在stackoverflow或cakephp google group上或通过google搜索找到解决方案。
我已经在两个版本的cakephp（1.2和1.3）上工作过，我也尝试过Zend框架（我也尽了最大的努力，但在实现布局时却被框架卡住了）。
但是在cakephp上花了一年多的时间之后，我很自豪地说，它是最好的工作框架。

框架的目标通常是更好的代码组织、组件的可重用性、可测试性，以及通用性、应用程序质量和可维护性。这不可能是更面向性能的选择。
我得到了运行symfony的网站，速度相当快，基准接近原始的静态HTML模板。
当使用框架（和ORM，如Doctrine）时，性能问题可能比将spagetti代码放入HTML静态页面时发生得更快。这听起来很正常：更多的处理、更多的验证、模式依赖性、更多的要解析的代码等。
如果你想让应用程序运行得更快，基本上有两种方法：
1.获得更快的硬件，它的成本，但可以是值得的，如果这个成本是低于程序员和工程师的成本，这是通常的情况。
1.优化软件时，更大的一步是在多个级别上使用缓存：操作码、数据库查询结果、任何重对象、HTML呈现（部分和整体）。
对于设计良好的MVC应用程序，您可以将性能作为一个孤立的问题进行管理，使用分析器查看应用程序的瓶颈并逐一处理它们（同样，优化也可以在硬件方面进行）。
选择一个PHP框架不应该在博客文章上看到的各种性能测试，他们不可能是客观的。在我看来，所有主要的MVC框架都可以用来建立性能网站，这是所有的优化问题。
如果你和你的团队更熟悉Symfony、CakePHP或Zend，那么就去做吧。一旦你的应用程序正常运行，你就可以处理性能优化，任何框架都有解决方案。
如果团队经验太广泛，并且每个人都有自己的偏好，那么我个人建议使用Symfony，因为它的缓存功能是与框架一起内置的（我不知道其他人的偏好）

这些差异将可以忽略不计，因为您的慢速部分总是I/O -数据库、文件系统等。确保您有一个良好的数据缓存策略，不要在代码中做任何过于愚蠢的事情，这不会有什么关系。

Symfony的设计是缓慢的，如果你看看请求的生命周期和结果是如何序列化的，任何定制都对性能有很大的影响，但这也是由于通用目标编程。你不能把实体作为对象，并期望它工作得很快。Symfony非常成功地使实体只服务于一个目的，即条目的反射。然而，他们没有利用这一优势来提高性能。由于每个条目都在被构造，并经历所有关于每个条目的序列化/规范化例程的“猜测”，更糟糕的是，当涉及到需要自定义数据时，这会导致转换器或RSM或其他什么，同时没有利用上下文概念，他们使用上下文概念可以最小化查询计数，当涉及到教义工作单元时。通常在php中，对于串行化数据快速API，条目必须不被示例化为对象，且仅应使用实体描述，然后生成输出。要使symfony上的api在遵循其原则的同时快速运行需要做大量的工作，而且似乎没有人在朝着这一方向努力。在这种情况下，只使用DQL，编写您的RSM，并在您正在工作的项目之上创建您自己的“apiprotPlatform”项目。然而，这种解决方案只适用于只有api的后端项目，因为您最终会有数组输出。尽管后一种情况影响了绝大多数框架。