我正在处理一个特定页面加载时间较慢的Symfony2项目。有问题的页面确实运行了一个非常大的查询，其中包含16个连接，我原以为这是罪魁祸首。也许是这样，而我正在努力正确地解释调试工具栏中的数字。以下是基本统计数据：
我在三种不同的环境中或多或少得到了相同的基本结果：
鉴于初始化+查询+渲染时间远不及TOTAL TIME数字，我想知道还有什么其他方法可以发挥作用，以及其他方法我可以去识别瓶颈。目前，查询设置为提取->getQuery()->getResult()。从我所读过的内容来看，这可能会带来巨大的开销，因为返回完整的结果对象意味着每个X对象都需要保持水分。 （为了上下文，我们在讨论这种情况下少于50个顶级/父对象）。因此，许多人建议使用->getQuery()->getArrayResult()来返回简单数组而不是水合对象，以大幅减少开销。这对我来说听起来很合理，尽管它需要一些模板更改才能使页面呈现替代类型的结果，但我试了一下。它确实减少了总时间，但通常不明显（从21530ms减少到20670 ms）。
我也一直在使用Docker，并决定在 php 7 上运行Symfony 2.8代码中使用原始getResult()查询的最小docker环境。这个环境使用的是内部的php webserver，而不是Apache，我不确定是否应该/可能有任何影响。虽然页面加载速度仍然很慢，但它在php 7上似乎有了明显的改进。另一个有趣的部分是，虽然TOTAL TIME减少了很多，但其他大多数开发人员工具栏都是 up ：
因此，页面加载php 7的时间是加载php 5.4 / 5.6所需时间的35％。这很有用，并为我们升级的原因提供了一个令人信服的论据。话虽这么说，我仍然有兴趣弄清楚解决TOTAL TIME和 [初始化时间+查询时间+渲染时间] 之和之间存在巨大差异的常见因素。我猜我不应该期望这些数字准确对齐，但我注意到，虽然仍然关闭，但它们在php 7 Docker环境中比在php 5.4 / 5.6环境中更接近
为了清楚起见，docker容器自然地以 php.ini memory_limit设置为-1旋转。其他环境使用256M，我甚至拨打了高达1024M，但没有看到性能上的明显变化，以及＆＃34;峰值内存＆＃34;数字保持低位。我尝试用1024M重新创建Docker环境，并且没有注意到那里的差异。
提前感谢任何建议。
修改 我已经通过php的内部网络服务器测试了通过php 5.6 / Symfony 2.8环境加载页面，并且它在大约一半的时间内加载。仍然没有那么好的PHP 7 +内部服务器，但至少它给了我一个坚实的领导，我的Apache设置的一些事情至少显着相关（虽然不一定是唯一的罪魁祸首）。 欢迎任何/所有建议/建议！