我目前正在开发一个 n 层系统并与一些数据库性能问题作斗争。 我们一直在研究的一个领域是数据库服务器和应用程序服务器之间的延迟。在我们的测试环境中 两个盒子之间的平均 ping 时间在 0.2 毫秒左右，但在客户端站点上，它在 8.2 毫秒左右。就是它 我们应该担心什么？
对于您的平均系统，你们认为合理的延迟是多少？您将如何测试/测量延迟？
卡尔
【问题讨论】：
标签： database performance latency
很抱歉回复非常不及时，但是当我在寻找其他人在他们的应用服务器和数据库服务器之间实现的网络延迟的指标时，我偶然发现了这个问题。无论如何，我注意到其他答案
无论如何，简而言之：是的，网络延迟（通过 ping 测量）可以产生巨大的差异。
如果您的数据库响应为 0.001 毫秒，那么您将看到从 0.2 毫秒到 8 毫秒 ping 的巨大影响。我听说数据库协议很健谈，如果这是真的，则意味着它们会受到网络延迟较慢的影响，而不是 http。
而且很可能，如果您正在运行 1 个查询，那么添加 8 毫秒以从数据库中获取回复并不重要。但是，如果您正在执行 10,000 次查询，这些查询通常发生在错误代码或未优化使用 ORM 的情况下，那么您将需要额外等待 80 秒才能进行 8 毫秒的 ping，而对于 0.2 毫秒的 ping，您只需等待 4 秒。
作为我自己的政策，我从不让客户端应用程序直接联系数据库。我要求客户端应用程序始终通过应用程序服务器（例如 REST Web 服务）。这样一来，如果我不小心遇到了“1+N”ORM 问题，那么它的影响就没有那么大了。我仍然会尝试解决根本问题...
【讨论】：
简而言之：不！
您应该监控的是查询的全局性能（即传输到数据库 + 执行 + 传输回您的服务器）
您可以做的是使用性能计数器来监控您的查询通常需要执行的时间。 您可能会看到您的结果超过毫秒区域。
没有“合理的延迟”之类的东西。您应该考虑“项目的合理延迟”，这取决于您正在从事的工作。 人们对实时交易平台和只读业余网站的期望不同。
【讨论】：
在基于 linux 的服务器上，您可以使用 tc 命令自己测试延迟的影响。
例如，此命令将为通过 eth0 的所有数据包添加 10 毫秒的延迟
tc qdisc add dev eth0 root netem delay 10ms
使用此命令消除延迟
tc qdisc del dev eth0 root
更多详情请点击此处： http://devresources.linux-foundation.org/shemminger/netem/example.html
所有应用程序都会有所不同，但我确实见过 10 毫秒延迟对系统性能产生重大影响的情况。
【讨论】：
answers.com 的一位负责人表示，根据他们的研究，网页加载的 400 毫秒等待时间大约是他们第一次开始让人们取消页面加载并转到其他地方的时间。我的建议是查看从最初的客户请求到履行的整个过程，如果您在那里做得很好，则无需进一步优化。 8.2 毫秒 vs 0.2 毫秒在数学意义上是指数级的，但从人类意义上来说，没有人能真正感知到 8.0 毫秒的差异。这就是他们在比赛中完成照片的原因；）
【讨论】：