高性能网络应用的最佳实践 [英] Best practices of high-performance network applications

问题描述

在测试出来，我已经写了Windows 7旗舰版64位一个UDP组播服务器，我遇到了一个最奇怪的事情。播放音乐foobar2000的背景显著的改进的服务器的传输速率，又能发生轻微的丢包。立即打开音乐关闭扔下传输速率低于可接受的水平，但也产生了0丢包。 （我有一个客户端应用程序，它会谈到服务器并报告未确认的数据包）

While testing out a UDP multicast server that I've written on Windows 7 Ultimate x64, I came across a most curious thing. Playing music with foobar2000 in the background significantly improved the server's transmission rate yet also incurred minor packet loss. Turning the music off immediately dropped the transmission rate to below acceptable levels but also produced 0 packet loss. (I have a client application which talks to the server and reports back unacknowledged packets)

我知道Vista的（及以上）限制行为，使媒体和网络应用中发挥得很好，但我肯定没有想到，播放音乐将提高网络性能，也不是说把它关掉降低网络性能，让显著。

I am aware of Vista's (and up) throttling behavior to make media and network applications play well together, but I certainly did not expect that playing music would improve network performance, nor that turning it off degraded network performance so significantly.

什么在我的服务器应用程序，我可以做这个从code的角度看，以便它一贯执行是否播放音乐或不能在Vista和起来？我当然想避免地告诉我所有的客户如何调整自己的注册表，以获得可接受的传输速率，并且还要避免他们只是为了得到可接受的传输速率，以及玩音乐。应用程序应该只是工作在我看来。

What can I do about this from a code standpoint in my server application so that it performs consistently whether playing music or not on Vista and up? I would certainly like to avoid having to inform all my clients about how to tweak their registry to get acceptable transmission rates, and would also like to avoid having them simply "play music" in order to get acceptable transmission rates as well. The application should "just work" in my opinion.

我想的解决方案包括沿进程优先级，MMCSS，或可能还有一些其他的晦涩的Windows API调用行的东西得到它做正确的事（TM）在这里。

I'm thinking the solution involves something along the lines of process priorities, MMCSS, or possibly some other obscure Windows API call to get it to do The Right Thing(TM) here.

此外，对不起，但创建一个可重复的测试案例是工作的一个不平凡的量。出现该限制行为，只有当驱动程序的物理NIC正在积极做工作，不能使用环回接口进行复制。人们会需要一个客户端实现，服务器实现和物理网络硬件来测试。

Also, sorry but creating a reproducible test case is a non-trivial amount of work. The throttling behavior occurs only when the driver for the physical NIC is actively doing work and cannot be reproduced using the loopback interface. One would need a client implementation, a server implementation, and physical network hardware to test with.

推荐答案

你观察你是什么媒体播放器本机的时钟精度设置为1毫秒的副作用。

What you observe is the side-effect of your media player setting clock resolution of your machine to 1 ms.

这种情况只有在播放

的副作用是 - 你的应用程序有更小的时间片，这imporves您的应用程序，因为你可能有很多的CPU，从您的应用程序被盗，并用较长的时间片 - 更长的时间

The side-effect is - your app has smaller timeslices and this imporves your app because you probably had lot of CPU stolen from your app and with longer timeslices - for longer time.

要测试它，你可以简单地设置您的应用程序中的计时器分辨率为1毫秒和比较性能的不媒体播放。

To test it you can simply set the timer resolution within your app to 1ms and compare performance without media playing.

应该是一样的，如果没有clocres设置，但与媒体的播放。

Should be the same as if with no clocres setting but with media playing.

这篇关于高性能网络应用的最佳实践的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！