5

从中我们可以清晰看出,在6核心机器上,最大每秒请求数从20k降低到了8k。显然,增加了休眠时间之后,由于大量的TCP连接数,对结果产生了较大影响。不过此时总的连接数已经接近我们期望的700k的水位。

里程碑 #1

我们如何增加TCP连接数?非常简单,只需要通过sleep参数增加休眠时间。我们持续增加该参数,最终停留在60秒,既最终平均延迟在30秒左右。

Vegeta提供了一个有趣的参数:请求成功率。我们发现在该休眠时间下,只有50%的请求成功率。参见下面数据:

 

通过设置60000毫秒休眠时间,我们达到了高达400k TCP连接数,同时每秒请求数8k的结果。图表中60000R中的R代表随机。

对此我们发现的第一个问题是Vegeta的默认请求超时时间是30秒,因此会有50%的请求失败。因此我们将这个超时时间设置撑了70s,以避免在后续测试到再次遇到。 

修改了客户端超时时间之后,我们很容易的达到了700k个连接。唯一的问题是连接数这个数据不稳定,只是峰值数据能够达到。因此系统峰值连接数能够达到600k到700k,但是并不能长时间维持。

我们希望能够达到这样的效果:

该图展示了连接数稳定维持在780k。上面表格数据中,每秒钟请求数非常高,但在实际生产环境中,单台HAProxy机器上的请求数要少很多(大约在300左右)。

但是我们如果大幅削减生产环境中的HAProxy机器(目前大约在30台,这意味着集群每秒请求数为30*300大约9k),首先遇到的瓶颈会是TCP连接数,而不是CPU。

因此我们决定尝试验证每秒请求数900、网络带宽30MB/s和2.1M TCP连接数的场景下验证。我们使用该场景是因为这是生产环境单台HAProxy机器压力的3倍。

另外,目前仅仅给HAProxy分配了6个内核。我们希望测试分配3个内核时的性能,因为这是我们模拟生产环境机器配置的最简单方式(前面提到过,我们的生产环境机器配置是4核30GB内存。)因此设置nbproc = 3是最方便的方式。

记住现在我们使用的机器是16核30GB内存,其中3个内核分配给HAProxy。​