我在一个小型集群上使用了一种负载均衡器，能够在零持续时间的请求上实现> 2000rps（t.i.工作节点立即满足的请求）。 但是一旦请求停止为零持续时间并开始甚至1ms，性能立即下降> 10x。在两个方向上传输的数据是相同的，大小约为2kb。 这肯定与集群饱和或网络吞吐量无关，因为200rps的1ms请求是非常小的负载，网络是10Gbit。此外，负载均衡器和工作节点上的CPU负载仅为2-5％。
我想知道这是否与OS调度程序或OS网络堆栈的某些病态行为有关（t.i.对于非常短的交互存在一些特殊情况行为）。
我如何诊断原因？哪些人要观看？使用什么工具或方法？
（以防万一有人只知道我的特定问题的答案，我在谈论MS HPC Server 2008 R2的“WCF代理”，在Windows Server 2008 R2上通过Hyper-V运行）
答案 0 :(得分：1)
您可以做的一件事是使用ETW跟踪来尝试了解WCF作业运行时节点正在执行的操作。在HPC服务器上，我有时会使用clusrun xperf来收集所有或特定节点上的跟踪。您可以使用许多工具来分析ETW跟踪，包括xperf本身。我没有使用HPC SOA（WCF）做过任何认真的工作，但我确实编写了一个简单的WCF光线跟踪应用程序，然后使用xperf在几个节点上对其进行了分析。
答案 1 :(得分：1)
原来这是一个完全与网络无关的问题，与HPC Server的调度机制的特性有关。我通过在WCF服务配置文件的loadBalancing部分中将配置选项“serviceRequestPrefetchCount”调整为0来解决了该问题。
答案 2 :(得分：0)
我假设有一些共享资源与某种锁定系统到位？锁定瓶颈？没有看到系统就很难猜到。
你有办法描述工人吗？他们大部分时间都花在了什么上，特别是在快速和慢速情景中？