网络延迟高的原因
我的网站现在运行速度极其缓慢。 Safari 的检查器和 Firebug 都报告说大部分加载时间是由于延迟造成的。实际下载发生在不到一秒的时间内。有很多数据库活动在进行（尽管其指标表明它非常健康），但是还有什么会导致真正的高延迟呢？这是纯粹的网络问题还是我可以对应用程序进行更改以改善延迟数字？
我使用 YSlow 来帮助确定性能改进，但总的来说，我没有看到它报告任何看起来疯狂不合理的内容。当然，有改进的机会，但似乎不会导致我看到的巨大加载时间。
谢谢。
更新
一些背景和指标，以防有用。这是一个 CakePHP 应用程序，我使用我的 UsersController::login 操作作为基准。为了确定应用程序代码在其中发挥的作用，我在输入 UsersController::beforeFilter() 后立即打印了堆栈跟踪。以下是输出：
UsersController::beforeFilter() - APP/controllers/users_controller.php, line 13
Controller::startupProcess() - CORE/cake/libs/controller/controller.php, line 522
Dispatcher::_invoke() - CORE/cake/dispatcher.php, line 187
Dispatcher::dispatch() - CORE/cake/dispatcher.php, line 171
[main] - APP/webroot/index.php, line 83
加载时间，如 Safari 的检查器所示，范围从 11.2 秒 到 52.2 秒。这似乎让我远离应用程序代码，也许还有我的主机的一些东西，但也许我完全误解了这一点或过度简化了它？
I have a site that is moving incredibly slowly right now. Both Safari's inspector and Firebug are reporting that most of the load time is due to latency. The actual download is happening in less than a second. There's a lot of database activity in play (though the metrics on that indicate that it's pretty healthy), but what else can cause really high latency? Is it a purely network thing or are there changes I can make to the app to improve the latency numbers?
I'm using YSlow to help identify performance improvements, but on the whole, I don't see it reporting anything that seems crazy unreasonable. Opportunities for improvement, certainly, but nothing that seems like it would cause the huge load times I'm seeing.
Thanks.
UPDATE
Some background and metrics, in case it's useful. This is a CakePHP application and I'm using my UsersController::login action as the benchmark. For the sake of identifying how much of a factor the application code plays in this, I've printed a stacktrace immediately upon entering UsersController::beforeFilter(). Here's output:
UsersController::beforeFilter() - APP/controllers/users_controller.php, line 13
Controller::startupProcess() - CORE/cake/libs/controller/controller.php, line 522
Dispatcher::_invoke() - CORE/cake/dispatcher.php, line 187
Dispatcher::dispatch() - CORE/cake/dispatcher.php, line 171
[main] - APP/webroot/index.php, line 83
Load times, as shown by Safari's inspector range from 11.2 seconds to 52.2 seconds. This would seem to point me away from the application code and maybe something with my host, but maybe I'm completely misinterpreting this or oversimplifying it?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果您无法直接识别应用程序中移动缓慢的组件，那么在此过程中还有许多其他步骤肯定会减慢您的网站速度。每当我遇到异常长的轮询时，我通常首先查看本地 DNS，然后再查看我的托管 DNS。有时，缓存刷新（对于他们而言，而不是您而言）可能会导致大量轮询，直到他们的数据库跟上。
否则，他们实际上可能发生服务中断，并且您的请求正在向他们的辅助或备份服务器发出。如果在域解析方面一切看起来都很好，那么您的托管提供商可能会遇到服务中断，这种中断可能会采取多种不同的形式，例如从备份中提供静态内容或过度分配共享资源，直到一切正常运行。当共享云架构出现故障时，您可能会遇到大量所谓的“限制”。从好的方面来说，在这种情况下不会出现完全中断的情况。
有一次，这只是在共享网格配置中，我的处理器见鬼了。奇怪的是，静态内容仍然从备份中提供服务，但它仍然对我们的数据库（位于不同的服务器上）进行轮询，并导致我们的帐户由于过度分配而
节流备份。这不是我们的错，但主持人开始发送令人讨厌的电子邮件，指责我们过度的长时间民意调查。这个故事的寓意是，如果这不是您的应用程序，并且是出乎意料的，那么我敢打赌您会发现一些硬件故障或配置错误。现在我也想到了这一点，如果您联合一些外部内容（无论是服务器端还是浏览器端），它可能并不完全在您的责任链中。例如，如果您通过订阅者服务投放广告，则它们可能会出现高负载期或中断。这些只是我为缩小罪魁祸首范围而采取的步骤。
If you cannot identify directly a slow moving component of your application, there are a number of other steps along the way that can certainly slow your site down. Whenever I'm experiencing unusually long polling, I typically start by looking at the local DNS and then onto my hosted DNS. Sometimes a cache refresh (on their part, not yours) can cause a lot of polling until their database has caught up.
Else, they might actually have a service outage and your requests are being made to their secondary or backup server. If everything seems fine in terms of domain resolution, your hosting provider might be experiencing a service outage that can take a number of different shapes like serving static content from their backups or over-allocating shared resources until everything is running as it should. You can experience a ton of what they call
throttlingon shared cloud architectures when they have a box go down. On the plus side, you don't have a total outage in this circumstance.One time, and this was just in a shared grid configuration, I had a processor go to hell. The bizarre part of it was that static content was still serving from a backup, but it was still polling against our database (which was on a different server) and causing our account to
throttlebecause of over allocation on the backup. Wasn't our fault, but the host started sending nasty emails about our excessive long-polls. Moral of the story is, if it's not your application, and it's out of the blue, somewhere along the line I'll bet you'll find some hardware failure or misconfiguration.Also now that I think of it, if you are syndicating some outside content (be it server or browser side) it might not be in your chain of responsibility altogether. If you are serving ads for example from a subscriber service, they might be having a high-load period or outage. These are just the steps that I would take to narrow down the culprit.
也许这不是你的解决方案，但当我有狗慢游猎（和FF）时，我只需将DNS服务器更改为opendns（208.67.222.222、208.67.220.220），所有问题都得到解决。
Probably this will be not the solution for you, but when I has doggy slow safari (and FF too) I simply changed the DNS servers to opendns (208.67.222.222, 208.67.220.220) and all my problems are resolved.