我们定期收到关于 GUI（浏览器页面）响应不佳的投诉，我们需要对此进行探索。我正在寻找一种快速且便宜的初步检查方法，以查看问题是网络延迟还是服务器性能。有没有人遇到过有关 ping 时间和感知到的 GUI 响应的讨论？我知道 GUI 响应很复杂，但如果我们能找到或开发一条经验法则，例如“嗯，ping 超过 200，可能是网络问题”，那就太好了。理想情况下，这存在于用户机器上的脚本中，以便我们可以看到他们看到的延迟......（BASH，Linux）。引用一个好的讨论页面将是一个很好的答案，其他源材料的推荐也是如此。
10/3：感谢大家的所有建议。虽然这些建议很有用，我会研究它们，但我在这个查询中寻求的主要内容是快速而粗略的数量级查看。例如，我假设如果 ping 时间为 1 毫秒，虽然不确定，但这表明网络延迟不是问题，请先查看服务器；而 ping 时间超过 500 毫秒则表明我可能正在查看一台无辜的服务器，该服务器正遭受网络服务问题的困扰。重点是快速而不是精确；我应该先查看哪里。如果我的假设是错误的，那对我来说将非常有帮助！
答案1
至少需要两次完整的网络往返才能开始加载页面，而且这是在 DNS 查找之后，有时甚至需要更长时间。因此，请计算您的 ping 时间并将其翻倍，以了解它们对页面加载的影响。
Firebug 或 Chrome 的开发者工具等浏览器调试工具会告诉你在加载页面时时间具体花在了哪里，这应该能让你更好地了解是什么导致速度变慢。例如，这是我的 Chrome 开发者工具告诉我在加载 Google 主页时时间花在了哪里：
答案2
看一眼http://newrelic.com。注册免费帐户，您将获得专业版的试用期，这将使您清楚地了解瓶颈在哪里。
要点是这样的：GUI 中的响应（或称为 Apdex 分数的最终用户体验）是浏览器请求和浏览器完成页面渲染之间发生的几件事的结果。
我经常发现，一些小问题，比如糟糕的 CSS 表达式或 HTML 文档中存在太多复杂节点，都会导致浏览器长时间无法呈现页面。有时，愚蠢的外部 javascript（如非异步模式下的 Analytics）会阻塞页面。
正如 Shane 提到的，Firebug（Firefox）和 Chrome Inspection（右键单击并检查元素，然后选择网络选项卡->点击刷新）等工具可以告诉您瓶颈所在的第一个位置。
如果瓶颈是应用程序，那么 Newrelic 之类的工具可以为您提供代码中哪些调用很慢的跟踪等等。
Bottomlime：这个过程涉及很多事情，但你必须首先遵循消除的过程，并解决更大的性能问题。