高性能网络应用最佳实践
在测试我在 Windows 7 Ultimate x64 上编写的 UDP 多播服务器时，我遇到了一件最奇怪的事情。在后台使用 foobar2000 播放音乐显着提高了服务器的传输速率，但也造成了轻微的丢包。关闭音乐会立即将传输速率降低到可接受的水平以下，但也会产生 0 数据包丢失。 （我有一个客户端应用程序，它与服务器通信并报告未确认的数据包）
我知道 Vista（及更高版本）的节流行为可以使媒体和网络应用程序很好地协同工作，但我当然没想到播放音乐会改善网络性能，也不是关闭它会显着降低网络性能。
从代码的角度来看，我可以在我的服务器应用程序中对此做些什么，以便无论是否在 Vista 及更高版本上播放音乐，它都能始终如一地执行？我当然希望避免必须通知我的所有客户如何调整他们的注册表以获得可接受的传输速率，并且还希望避免让他们简单地“播放音乐”以获得可接受的传输速率。我认为该应用程序应该“正常工作”。
我认为解决方案涉及进程优先级、MMCSS 或可能其他一些晦涩的 Windows API 调用，以使其在此处执行正确的操作 (TM)。
另外，抱歉，创建可重现的测试用例是一项不小的工作量。仅当物理 NIC 的驱动程序正在主动工作且无法使用环回接口重现时，才会发生限制行为。需要一个客户端实现、一个服务器实现和用于测试的物理网络硬件。
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)
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.
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.
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.
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
您观察到的是媒体播放器将机器的时钟分辨率设置为 1 毫秒的副作用。
这只发生在游戏期间
副作用是 - 您的应用程序具有较小的时间片，这会改善您的应用程序，因为您可能从应用程序中窃取了大量 CPU，并且时间片较长 - 时间较长。
要测试它，您只需将应用内的计时器分辨率设置为 1 毫秒，然后比较不媒体播放的性能。
应该与没有 clores 设置但播放媒体时相同。
What you observe is the side-effect of your media player setting clock resolution of your machine to 1 ms.
This happens only during the play
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.
To test it you can simply set the timer resolution within your app to 1ms and compare performance without media playing.
Should be the same as if with no clocres setting but with media playing.
自从我编写网络协议相关代码以来已经很多年了，但我会提供一个猜测。
我怀疑这是吞吐量和延迟的问题。播放音乐会引入 I/O 争用并在传输数据包时增加延迟。但是，增加的延迟可能会导致数据包排队，从而批量增加吞吐量。
要在代码中解决此问题，您可以尝试自己批量发送数据包。我假设您在数据准备好时将每个数据包发送到系统进行传输。将多个数据包分组并同时发送到系统。即使只是一组两个或三个数据包也可能会产生巨大的差异，特别是如果您在每个系统调用之间引入您自己的小延迟。
我无法通过 Google 快速搜索找到任何直接相关的链接。不过，您可以在 Linux 网络调优讨论 或此常见问题解答中介绍了诸如批处理等提高吞吐量的技术。
It has been many years since I wrote network protocol related code, but I'll offer a guess.
I suspect this is an issue of throughput and latency. Playing music is introducing I/O contention and adding latency in transmitting the packets. However, the added latency is likely causing the packets to queue and thus batched increasing throughput.
To address this in your code, you might try sending the packets in batches yourself. I am assuming that you are sending each packet to the system for transmission as the data becomes ready. Group multiple packets and send them to the system at the same time. Even just a group of two or three packets could make a dramatic difference especially if you are introducing your own small delay between each system call.
I couldn't find any directly relevant links from a quick search on Google. However, you can see the concept in this discussion of network tuning for Linux or in this FAQ which describes techniques such as batching to improve throughput.
Foobar 有许多由不同人编写的插件。这些可能是导致您出现问题的原因。我建议你更接近真正的原因。每次禁用插件时，尝试一一关闭插件来执行测试。
希望这个想法能有所帮助。
Foobar got many plugins written by different people. These may be the cause of your issue. I propose you to come closer to the real reason. Try to switch off plugins one by one performing your test each time a plugin is disabled.
Hope the idea will help.
这听起来像是 TSP/IP 基于其原始算法来管理吞吐量。这里的白皮书应该提供更多背景信息。
http://www.asperasoft.com/?gclid=CICSzMqD8Z0CFShGagod_ltSMQ
他们的产品是一个运行良好的UDP协议。
This sounds like TSP/IP managing throughput based on it's primitive algorithm. The white paper here should give more background.
http://www.asperasoft.com/?gclid=CICSzMqD8Z0CFShGagod_ltSMQ
Their product is a UDP protocol that works very well.