为何相同并发下，RabbitMQ等发布/订阅系统不同请求量测试中吞吐率稳定？

• 固定并发数已经锁死了测试场景下的系统稳态处理速率
  性能测试里的吞吐率，本质是单位时间内系统成功处理完的请求总量。全程把并发数固定在200的前提下，不管总请求压1000还是10000，服务端收到的请求流密度根本没有变化：200个并发连接会一直以固定节奏发请求，只要流量没撞到服务端的处理瓶颈，系统能跑出来的处理上限就不会变。你看到的RabbitMQ两次测试的微小差值，根本不是性能波动，只是第一轮测试里的冷启动固定开销，被第二轮更长的请求序列给摊薄了而已。
• 发布/订阅系统的单条消息处理开销和总请求量无关
  不管是RabbitMQ、Apache Kafka，还是Pushpin、Faye这类系统，单条消息从接收到投递到订阅端的全流程，处理耗时不会因为累计处理了多少条消息就变多。只要测试期间没碰到内存打满、磁盘IO到顶、连接数触顶这类资源瓶颈，系统处理每一条消息的速度都是恒定的，算出来的单位时间处理速率自然不会有大幅起伏。
• 两次结果的微小差异完全在测试正常误差范围内
  1000次总请求的第一轮测试里，测试流程的一次性开销（客户端和服务端建TCP连接、初始化队列/主题、加载路由规则、TLS握手这些）会占总耗时的一定比例，轻微拉低平均吞吐率；等总请求提到10000次的时候，这些一次性开销的占比直接从千分之一级掉到万分之一级，最后算出来的吞吐率涨个1%-3%是非常正常的事，这点差异根本算不上性能变化。

真要测出吞吐率的明显变化，光拉长总请求量是没用的。要么逐步加并发直到系统开始排队、资源跑满，要么把总请求压到极短的量级（比如仅几十次请求，那时候固定开销的影响占比极高，吞吐率会出现明显回落），不然只要并发固定、系统没到瓶颈，测出来的吞吐率基本都是稳定的。

内容的提问来源于stack exchange，提问作者Apostolos Lazidis