01

引言

在软件开发过程中，性能测试是至关重要的一个环节。

在完成开发之后，对系统进行性能测试可以帮助发现系统存在的性能问题，从而及时进行优化，提高系统的响应速度、吞吐量、并发性等指标。

性能测试瓶颈分析及调优方案是性能测试的重要步骤之一，下面我们将详细介绍其步骤和方案。

如今谈起http协议，想必IT人都懂，无论基于Web端还是App端应用、游戏开发等领域，应用非常广泛。

如何才能让http协议让不懂计算机的人也能明白它的重要性？

这个案例主要讲解如何通过http协议的细节来判断cookie、session、会话保持等相关知识点。

02

一、内容简介

在此先大概介绍下整个请求链路，JMeter→nginx集群→k8s集群(应用服务部署在容器里，2个pod分别在不同的node上)→数据库，接口使用的是http协议。

03

二、寻找问题的本质根源

如果在压测过程中发现所有的请求只打1个pod中，这个pod的资源利用率达到80%以上，而另外一个pod无压力，通过查看应用日志，发现没有任何请求打到这个pod上，判断是负载不均衡带来的问题。

04

三、分析定位问题

根据应用的请求链路信息，通常看到这个现象，脑海里想到的第一个想法首先是查看k8s的负载均衡策略，这里简单介绍一下，目前kubernetes提供了两种负载分发策略：

①如果不定义，默认使用kube-proxy的策略，比如随机、轮询；

②基于客户端地址的会话保持模式，即来自同一个客户端发起的所有请求都会转发到固定的一个Pod上。

通过查看service的yaml配置，发现service没有配任何IPVS的分发策略。

细想还会是什么原因影响请求的转发呢？

大胆假设很可能是另外一个pod所在的node设置网络策略比如限速等引起的，这可以通过最简单的方式进行快速验证，即将pod驱逐到其它node上进行验证，可惜的是问题并没有解决。

由此证明此问题不是k8s和node引起的。

通过前面的链路判断，只能再往前分析前一个组件了，即nginx集群配置负载均衡策略导致。

Nginx常见的负载均衡策略有，随机、轮询、ip_hash、weight等，其中可能会引起负载不均衡的有ip_hash和weight。

通常在企业内，测试并没有很高的权限，而且每个组件都会有对应的负责人，想到这只能联系nginx的负责人帮忙查看了，很遗憾获得的回馈是nginx配置是轮询策略，也就是不是nginx配置引起的。

再往前思考一步莫非是JMeter了，但是这次压测使用了5台不同的压力机进行发压，即使有1台压力机有问题，也不会引起后端服务负载不均衡。

此时我已无策可施，下面只能考虑应用层相关配置引起的问题，一层层深入分析。

从协议的角度来看，常见的有四层负载均衡和七层负载均衡，这次的应用使用的是七层负载均衡。

由于缺乏对http协议的深度理解，大脑中只知道接口协议包含哪些内容如请求头、响应头、cookie、session、URL、地址、参数等信息，实在想不出哪里会导致后端负载不均衡。

05

四、寻找问题解决方案

此时和开发还有k8s的负责人，大家在一起讨论原因，开发预估是配置session会话保持引起的。

再次阐述，会话保持是指在负载均衡器上的一种机制,可以识别客户端与服务器之间交互过程的关联性,做负载均衡的同时还保证一系列相关联的访问请求都会分配到一台机器上。

再次查看应用层的确开启了session会话保持功能。

如果仅开启session保持这个功能并不会引起负载不均衡问题。

因为JMeter使用了不同的压力机，后来通过分析可能是JMeter脚本参数化数据问题，结果发现Cookie中将jsessionid给写成唯一值了，这就导致了所有的请求都只会到同一台服务器上。

06

五、解决问题

最后我通过模拟不同的jssessionid解决了此问题。

07

六、结语

 

综上所述，通过这次性能测试案例分析与调优。

从中获得了一些心得与感悟，要实施好性能测试，不但需要一定的知识的深度与广度，而且要让性能测试人员站在一定的高度才能快速分析出问题的瓶颈。

最后需要开发配合一起排查解决问题，才能从根本上提升系统的性能，满足性能测试需求目标。