为什么Symfony2在基准测试中表现如此糟糕？这有关系吗？

Question

我和我的同事正在选择一个Web框架来开发一个高流量的网站.我们真的很擅长node.js + express和php + symfony2.两者都是伟大的框架,但我们有点担心Symfony2的,因为它似乎被大多数web框架跑赢那里.

以下是证明它的基准:http: //www.techempower.com/benchmarks/

出于这个原因,我们可能会使用的node.js +表达,但我仍然不知道为什么Symfony2的在基准执行如此糟糕.

Answer 1

最后,所有这些都归结为正确的缓存处理 ......

symfony或PHP通常比其他语言或框架慢,因此为您提供了快速创建丰富,安全和可测试的Web应用程序的工具.

如果您使用反向代理,如Varnish和ESI(边缘包括)并最终提供模板的部分,您真的需要通过symfony更新.你会有一个非常快速的经历.

此外,如果您使用像APC和优化数据库这样的操作码缓存,那么人类用户实际上不会注意到实际应用程序中几毫秒的差异.

根据要求,我会深入一点,并给你一些更多的想法.

缓存和性能

随着在与负载均衡,易于配置(厨师,木偶,...),而这一切时髦的东西配对几乎没有成本的云服务(S3,EC2,GAE,...)即时拍摄就变得轻松和负担得起的甚至小公司运行和管理大数据和/或高流量应用程序.

更多存储意味着更多的缓存空间 - 更多的计算能力意味着更快的缓存热敏.

如果人们谈论php或框架性能,你会经常听到的东西:

• facebook用php运行
• youp**n是用symfony开发的
• ...

那么为什么这些网站没有彻底崩溃？因为他们的缓存程序很聪明.

Facebook的

你知道如果你写一个状态更新,Facebook会怎么做？

它不会将其保存到具有所有状态更新的数据库表中,如果朋友访问了他的流,则在提供服务之前,将从数据库中获取所有其他朋友的状态.

facebook将您的状态写入您的所有朋友新闻流并开始加热他们的缓存.现在所有的流都准备好服务了,每当你的一个朋友访问他的流时,他将被提供缓存版本; 即时几乎不涉及代码执行.当缓存预热完成时,流将仅显示新创建的状态.我们在这里谈论ms ...

这告诉我们什么？在现代高频率的应用程序中,几乎所有内容都是从缓存提供的,用户不会注意到页面的实际计算是花费1毫秒还是5秒.

在"真实世界"场景中,最终用户将注意到框架之间的req/sec没有差异.即使使用微型缓存等简单的东西,你也可以让你的vps托管博客一旦你在黑客新闻的登陆页面上制作它就不会立即停止.

最后,更重要的是......我的框架是否提供了工具,文档以及教程和示例......以便快速轻松地完成整个操作.symfony对我有用!

如果你被卡住了......有多少人愿意并且能够回答你与绩效相关的问题？使用此框架已创建或将在不久的将来创建了多少个真实应用程序？

您可以通过选择框架来选择社区!

...好吧那是重要的部分......现在回到这些基准:)

基准和设置

在基准测试中的所有这些闪亮的颜色和花哨的图表,您很容易错过这样一个事实,即每个框架都只测试了一个设置(网络服务器,数据库......),同时您可以为每个框架配置各种各样的配置.

示例:您也可以使用symfony + doctrineODM + MongoDB,而不是使用symfony2 + doctrineORM + mysql.

MySQL ... MongoDB ...关系数据库...... NoSQL数据库...... ORM ...微ORMs ...原始SQL ......所有这些配置都混淆了------>苹果和橘子.

基准和优化

几乎所有基准测试的常见问题 - 即使只是比较php框架 - 在网络上发现,以及那些"TechEmpower Web框架基准测试"是不等的优化.

这些基准测试没有利用这些框架的可能(以及经验丰富的开发人员众所周知的)优化......至少对于symfony2和他们的测试这是事实.

关于最新测试中使用的symfony2设置的一些示例:

• 没有使用-o标志调用"composer install"来转储优化的类映射自动加载器(代码)
• 没有apc_cli = 1(问题),Symfony2将不会将APC缓存用于Doctrine元数据注释
• 整个DI容器注入控制器而不是只有少数必要的服务
• 因此使用setter注入 - >创建对象然后调用setContainer()方法而不是将容器直接注入构造函数(请参阅:BenchController extends Controller扩展ContainerAware)
• 别名($ this-> get('service_name'))用于从容器中检索服务而不是直接访问它($ this-> container-> get('service_name')).(代码)
• ...

列表继续......但我想你明白这是领先的地方.现在90个问题 ......一个无尽的故事.

发展与资源

服务器和存储等资源很便宜.真的很便宜......与开发时间相比.

我是一名自由职业者,收取相当高的费用.你可以得到2-3天的时间......或者是大量的计算能力和存储空间!

在选择框架时,您还可以选择一个快速开发工具包 - 这是一种武器,可以帮助您对抗从未完全满意,功能悄悄的客户......谁会为您的愿望付出代价.

作为代理商(或自由职业者),您希望在短时间内构建功能丰富的应用程序.你会遇到一些问题,你可能会遇到一些问题...可能与性能相关的问题.但是你也面临着开发成本和时间.

什么会更贵？额外的服务器或其他开发人员？