Apache请求/响应太慢

Question

我有一个Apache服务器，有16GB的Ram。脚本cap.php返回非常小的数据块（500B）。它启动一个mysql连接并进行简单的查询。 但是，在我看来，服务器的响应太长了。 我在Chrome中附上了Developer Tool Panel的屏幕截图。

除了SSL和TTFB之外，还有300毫秒的奇怪延迟（停顿）。 如果我从WebServer尝试卷曲：

 curl -w '\nLookup time:\t%{time_namelookup}\nConnect time:\t%{time_connect}\nPreXfer time:\t%{time_pretransfer}\nStartXfer time:\t%{time_starttransfer}\n\nTotal time:\t%{time_total}\n' -k -H 'miyazaki' https://127.0.0.1/ui/cap.php

Lookup time:    0.000
Connect time:   0.000
PreXfer time:   0.182
StartXfer time: 0.266

Total time:     0.266

有谁知道那是什么？

Answer 1

最后，我发现如果你使用SSL，那真的会更好，将KeepAlive指令切换到Apache确实很重要。见下图。

Answer 2

根据Chrome documentation：

  

<强>失速/阻断

     

请求在发送之前等待的时间。此时间包括代理协商所花费的任何时间。   此外，这一次将包括浏览器等待的时间   已建立的连接可供重复使用，   遵守Chrome每个原始规则最多六个TCP连接。

因此，这似乎是Chrome与网络通信而非服务器配置问题的客户端问题。由于您只提出一个请求，我认为我们可以排除每个来源的TCP限制（除非您有许多其他标签用尽这些连接）所以会猜测您的PC（网卡，RAM，CPU）或基础设施问题的限制（例如，您通过代理连接，设置该连接需要时间）。

您的卷曲请求似乎没有显示此延迟，因为它只有0.182的等待时间来发送请求（这可以通过https协商轻松解释）然后总共下载0.266（包括0.182） 。相比之下，使用Chrome时为0.700秒，因此无法理解为什么你说＆＃34;总时间相似＆＃34;什么时候对我来说显然不是？

最后我不明白你的后续回答。它看起来像你已经提出请求，大概是在最近的其他请求之后，因为它跳过了整个网络连接阶段（包括任何灰色停顿，蓝色DNS查找，橙色初始连接和紫色https连接）。所以当然这个更快。但它并没有在您的问题中与您的第一个屏幕截图进行比较，而是没有解决您的问题。

但是，你绝对应该使用keep-alives（默认情况下它们在大多数Web服务器中都处于打开状态，因此通常需要额外的努力来关闭它们）和https恢复技术（默认情况下不启用，除非你明确地将它添加到你的https config）使第一个之后不久发送的任何其他请求受益。但这些不会有利于会话的第一次连接。