keepalived+lvs结合nginx压力测试实践

最新推荐文章于 2023-05-14 20:52:34 发布

原创

最新推荐文章于 2023-05-14 20:52:34 发布 · 974 阅读

2 ·

CC 4.0 BY-SA版权

文章标签：

#LVS #Keepalived #压力测试

本文介绍了在面临5WQps需求时，通过kafka中间件、压力测试、内核调优、LVS、Keepalived及nginx的结合使用，逐步解决性能瓶颈的过程。经过优化，最终在多台服务器上实现短期8Wqps，长期4.5Wqps的吞吐量。然而，服务断开和nginx断开仍影响用户使用，提出了proxy_next_upstream_tries重试机制和check机制的优化方案。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

需求

最近做一个kafka的中间件，需求比较简单，就一个需求：支持的吞吐量为5WQps。

尝试

接口内容比较简单：根据topic，key，value发送到kafka一条数据。把代码撸好-单元测试-部署-单节点压测，然后使用比较熟悉的jmeter在本地测试。

问题一：此时就出现了第一个问题，无论开多少个线程并发去访问，Qps大概也就2000左右，嗯哼？！这完全不符合心理预期啊，一个异步发送kafka的接口就这点能力？不可能啊，瓶颈难道是kafka生产者 producer参数配置不对？
问题二：压测总条数达到5W条左右时，就会出现如下异常：

org.apache.kafka.common.errors.TimeoutException: Expiring 1 record(s) for t2-0: 30042 ms has passed since batch creation plus linger time

针对问题二，增大了request.timeout.ms配置，默认是30s，我修改成了60s。（ kafka配置参考）折腾了大半天，发现是网络的瓶颈，
本地到服务器使用的是vpn连接，带宽大概10Mbyte左右，这样就导致了发送队列的积累，最终导致部分数据发送超时！同时联想到问题一是同一个原因导致的。于是更换压力发起端到线上，jmeter换成比较有名的ab。

问题三：ab测试开启500个线程，吞吐量大约可以到达1WQps了，有点开心了，但继续往上压效果并不显著，并发达到1000多的时候ab就会报错：

apr_socket_recv: Connection reset by peer (104)

修改linux内核配置：
参考文件：1.参数含义 2. linux内核调优

kernel.panic=60
net.ipv4.ip_local_port_range=1024 65535
#net.ipv4.ip_local_reserved_ports=3306,4369,4444,4567,4568,5000,5001,5672,5900-6200,6789,6800-7100,8000,8004,8773-8777,8080,8090,9000,9191,9393,9292,9696,9898,15672,16509,25672,27017-27021,35357,49000,50000-59999
net.core.netdev_max_backlog=261144
net.ipv4.conf.default.arp_accept=1
net.ipv4.conf.all.arp_accept=1
net.ipv4.neigh.default.gc_thresh1=10240
net.ipv4.neigh.default.gc_thresh2=20480
net.ipv4.neigh.default.gc_thresh3=40960
net.ipv4.neigh.default.gc_stale_time=604800
net.ipv4.ip_forward=1
net.ipv4.conf.all.rp_filter=0
net.