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

问题描述

在测试我在 Windows 7 Ultimate x64 上编写的 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.

从代码的角度来看，我可以在我的服务器应用程序中做些什么，以便无论在 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.

这只发生在播放过程中

副作用是 - 您的应用具有更小的时间片，这会改进您的应用，因为您可能从应用中窃取了大量 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屋！