Symfony和CakePHP太慢而无法使用吗?

时间:2010-05-28 12:27:00

标签: php zend-framework cakephp symfony1 performance

到现在为止,我总是说CakePHP过于膨胀和缓慢。我真的不知道,我只看到了“一些”基准。我真正想知道的是,如果这两个框架(Symfony和CakePHP)太慢而无法以用户会感到沮丧的方式使用。我已经知道那些框架比其他替代方案慢,但这不是问题。

我问这个问题是因为我想创建一个项目管理Web应用程序,我仍然在几个框架之间犹豫不决。我在学习Zend方面遇到了一些麻烦,但是我还没有努力学习。

总而言之,除了上面的第一个问题,我还想问另一个问题:

如果我想创建一个项目管理工具(这是一个非常大的项目),考虑到开发时间,最终应用程序的速度以及最终产品的稳健性,您应该建议以下哪一项: / p>

  • Symfony的
  • CakePHP的
  • Zend Framework

另外我应该提一下,我不知道任何这些框架,我想学习其中一个(至少)。

5 个答案:

答案 0 :(得分:21)

基准测试的问题在于它们通常不适合现实世界。编写一个真实的应用程序,你会发现在速度方面,所有框架都在彼此的大约一个数量级内。它们都比你没有使用框架(并且知道如何编程)慢。

但是,您需要考虑的是权衡。框架牺牲了一点性能,以显着减少开发时间。对您来说更重要的是,原始的纯粹性能还是合理快速的开发时间? Facebook不会在他们的网站上使用RAD框架,但那是因为他们的表现比增加的开发时间更有价值。同样,一个拥有单一开发人员的小公司可能会从一个框架中受益更多,而不是相当小的性能损失(我说很小,因为对每个页面视图的影响很小。效果“加起来”,流量更高)。

我建议的是看一堆框架。试试看(大多数都有“博客”教程)。了解它们的工作原理。选择一个你喜欢的,然后玩一会儿。了解它的编码风格,以及它如何做事......最重要的是,了解它的运作方式。尝试了解细节背后的“原因”。使用框架的能力是恕我直言,直接关系到它的运作方式...除非你必须使用,否则不要使用你不舒服的东西。找一个“适合”你的人,然后坚持下去,直到你流利......

答案 1 :(得分:8)

我推荐cakePHP v1.3,因为它更快,更容易理解。 您将找到与此框架相关的非常好的帮助(文档和教程)文档写得很好。即使你被困在某个地方,你也可以在stackoverflow或cakephp google group上找到解决方案,或者在google上搜索。

我已经开发过两个版本的cakephp(1.2和1.3),我也尝试过Zend框架(我也尝试过我的关卡,但是在实现布局时却陷入了框架)。

但是在花了一年多的时间后,我很自豪地说,这是最好的框架。

答案 2 :(得分:6)

框架通常旨在更好地编写组织,组件的可重用性,可测试性以及概括,应用程序质量和组织。可维护性。这不是更注重绩效的选择。

我使用symfony运行的网站非常快,基准测试接近原始的静态HTML模板。

使用框架(和像Doctrine这样的ORM)比将spagetti代码放入HTML静态页面时更快地发生性能问题。这对我来说听起来很正常:更多的处理,更多的验证,模式依赖,更多的代码解析等等。

如果你想让应用程序更快,那么它们基本上就是这样:

  1. 获得更快的硬件,它的成本,但如果这个成本在程序员和工程师费用,通常就是这种情况。
  2. 优化软件,这种方式的更大一步是在多个级别上使用缓存:操作码,数据库查询结果,任何重物,html渲染(部分和整体)。
  3. 使用精心设计的MVC应用程序,您可以将性能作为一个独立的问题进行管理,使用分析器查看应用程序的瓶颈并逐一处理它们(再次,优化也可以在硬件方面)。

    PHP框架的选择不应该在博客网站上的各种性能测试中进行,它们不能是客观的。从我的角度来看,所有主要的MVC框架都可用于构建高性能网站,这都是优化问题。

    如果您和您的团队更了解Symfony,CakePHP或Zend,那就去吧。一旦您的应用程序功能正常,您就会处理性能优化,并且有适用于任何框架的解决方案。

    如果团队经验太宽,任何人都有自己的偏好,那么我会个人推荐Symfony,因为它的缓存功能内置于框架中(我不为其他人所知)

答案 3 :(得分:3)

差异可以忽略不计,因为你的慢速片段总是I / O--数据库,文件系统等。确保你有一个很好的数据缓存策略,并且不要在代码中做任何过于愚蠢的事情。没关系。

答案 4 :(得分:0)

Symfony 的目的是缓慢,如果您查看请求的生命周期以及结果如何序列化,任何自定义都会对性能产生很大影响,但这也是由于一般目标编程。您不能将实体作为对象并期望它快速工作。 Symfony 非常成功地使实体仅用于一个目的,即入口的反映,但他们并没有利用这一优势来提高性能。由于每个条目都在构建并经历所有关于每个条目的序列化/规范化例程的“猜测”,更糟糕的是,当涉及到导致转换器或 RSM 或其他不需要的自定义数据时,同时不采取他们使用的上下文概念的优势可以最大限度地减少涉及学说工作单元的查询次数。通常在 php 中,为了使 apis 快速序列化数据 - 不得将条目实例化为对象,并且只应使用实体描述然后生成输出。要让 symfony 上的 api 在遵循其原则的同时快速运行需要相当多的工作,而且似乎没有人为之努力。否则你可以像使用其他框架一样,在这种情况下只使用 DQL,编写你的 RSM 并在你正在处理的项目之上制作你自己的“apiplatform”项目。但是,此解决方案仅适用于 api-only 后端项目,因为您最终会获得数组输出。尽管后者影响了绝大多数框架。