数据库网络延迟
我目前正在开发一个 n 层系统并解决一些数据库性能问题。 我们一直在研究的一个领域是数据库服务器和应用程序服务器之间的延迟。 在我们的测试环境中 两个盒子之间的平均 ping 时间约为 0.2 毫秒，但在客户端站点上，其平均 ping 时间约为 8.2 毫秒。 就是它 有什么我们应该担心的吗？
对于你们的普通系统，你们认为什么是合理的延迟？你们将如何测试/测量延迟？
I am currently working on an n-tier system and battling some database performance issues.
One area we have been investigating is the latency between the database server and the application server. In our test environment the
average ping times between the two boxes is in the region of 0.2ms however on the clients site its more in the region of 8.2 ms. Is that
somthing we should be worried about?
For your average system what do you guys consider a resonable latency and how would you go about testing/measuring the latency?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
是的，网络延迟（通过 ping 测量）可以产生巨大的影响。
如果您的数据库响应为 0.001 毫秒，那么您将看到 ping 从 0.2 毫秒变为 8 毫秒产生的巨大影响。 我听说数据库协议很杂乱，如果属实，则意味着与 HTTP 相比，它们会更多地受到缓慢网络延迟的影响。
而且很可能，如果您正在运行 1 个查询，那么添加 8 毫秒来从数据库获取回复并不重要。 但是，如果您正在执行 10,000 个查询（通常是由于代码错误或 ORM 未优化使用而发生），那么对于 8 毫秒的 ping，您将需要额外等待 80 秒，而对于 0.2 毫秒的 ping，您只需等待 4 秒。
根据我自己的政策，我从不让客户端应用程序直接联系数据库。 我要求客户端应用程序始终通过应用程序服务器（例如 REST Web 服务）。 这样，如果我不小心遇到“1+N”ORM 问题，那么它的影响就不会那么大。 我仍然会尝试解决根本问题......
Yes, network latency (measured by ping) can make a huge difference.
If your database response is .001ms then you will see a huge impact from going from a 0.2ms to 8ms ping. I've heard that database protocols are chatty, which if true means that they would be affected more by slow network latency versus HTTP.
And more than likely, if you are running 1 query, then adding 8ms to get the reply from the db is not going to matter. But if you are doing 10,000 queries which happens generally with bad code or non-optimized use of an ORM, then you will have wait an extra 80seconds for an 8ms ping, where for a 0.2ms ping, you would only wait 4 seconds.
As a matter of policy for myself, I never let client applications contact the database directly. I require that client applications always go through an application server (e.g. a REST web service). That way, if I accidentally have an "1+N" ORM issue, then it is not nearly as impactful. I would still try to fix the underlying problem...
简而言之：不！
您应该监视的是查询的全局性能（即传输到数据库+执行+传输回服务器）
您可以做的是使用性能计数器来监视查询通常执行所需的时间。
您可能会看到结果超过毫秒。
不存在“合理的延迟”这样的东西。 您应该考虑“项目的合理延迟”，它会根据您正在处理的内容而有很大差异。
人们对实时交易平台和只读业余网站的期望不同。
In short : no !
What you should monitor is the global performance of your queries (ie transport to the DB + execution + transport back to your server)
What you could do is use a performance counter to monitor the time your queries usually take to execute.
You'll probably see your results are over the millisecond area.
There's no such thing as "Reasonable latency". You should rather consider the "Reasonable latency for your project", which would vary a lot depending on what you're working on.
People don't have the same expectation for a real-time trading platform and for a read only amateur website.
在基于 Linux 的服务器上，您可以使用 tc 命令自行测试延迟的影响。
例如，此命令将为所有通过 eth0 的数据包添加 10 毫秒的延迟，
使用此命令可消除延迟
更多详细信息请参见此处：
http://devresources.linux-foundation.org/shemminger/netem/example.html
所有应用程序都会有所不同，但我确实见过 10 毫秒延迟对系统性能产生重大影响的情况。
On a linux based server you can test the effect of latency yourself by using the tc command.
For example this command will add 10ms delay to all packets going via eth0
use this command to remove the delay
More details available here:
http://devresources.linux-foundation.org/shemminger/netem/example.html
All applications will differ, but I have definitely seen situations where 10ms latency has had a significant impact on the performance of the system.
answers.com 的一位负责人表示，根据他们的研究，网页加载 400 毫秒的等待时间大约是他们第一次开始让人们取消页面加载并转到其他地方的时间。 我的建议是查看整个流程，从最初的客户请求到履行，如果您做得很好，则无需进一步优化。 从数学意义上来说，8.2 毫秒 vs 0.2 毫秒是指数级的大，但从人类的角度来看，没有人能够真正感知到 8.0 毫秒的差异。 这就是为什么他们在比赛中拍完照片；）
One of the head honchos at answers.com said according to their studies, 400 ms wait time for a web page load is about the time when they first start getting people canceling the page load and going elsewhere. My advice is to look at the whole process, from original client request to fulfillment and if you're doing well there, there's no need to optimize further. 8.2 ms vs 0.2 ms is exponentially larger in a mathematical sense, but from a human sense, no one can really perceive an 8.0 ms difference. It's why they have photo finishes in races ;)