打破砂锅看原理，JMeter并发cookie问题小记

1 问题由来

近日，项目使用JMeter进行并发登录的压力测试，原则上使用的用户名应该是不同的，由于环境问题出现了同用户并发登录的情况，但现象与理论上存在偏差。

那么使用相同用户并发的时候服务器是一个session还是多个session？

如果使用同一用户并发对服务器是否起到了压测的作用？

同一用户并发和不同用户并发有什么区别呢？

2 问题复现

带着这几个问题，先看看现象。下图是使用相同用户并发10个的时候，通过服务器的在线用户功能查到的结果。

明显是同一用户（administrator），同一终端（172.16.61.45）并发了10个登录。界面能够看到sessionID都是不同的。开始认为同一用户并发就是多个session的同学是不是“洋洋得意”了？那么问个问题，为什么手工进行同一用户的多次登录时，只能让服务器产生一个session呢？比如使用chrome开两个标签页，第一个登录后，第二个不需要登录直接就登入了！如果第二个登出，第一个的会话也停止了。不要说两个标签页，就是两个窗口也是一样的情况？这个是不是有些矛盾？

3 原因分析

经过一番思考，抓包对比，网上查同用户多session的资料，最终问题集中在：服务器根据什么判断同一个session？

用户名，终端（IP或者MAC），还有就是cookie。

对于同一个浏览器，再次打开标签页或者再次打开窗口进行登录时，获取的是同一cookie。所以，人工登录时，只能得到一个session。

4 实践验证

为证实这个论点，可以模拟一次同一浏览器能维持两个session的现象。步骤如下：

（1）打开chrome，登录系统；

（2）新建一个标签页，清除浏览器cookie后登录；

（3）查看在线用户。

进一步验证，如果使用不同浏览器，如一个chrome，一个firefox登录，结果与预期一致：会出现不同的session。省略验证过程。

5 理论支撑

现在可以推断，JMeter的HTTP Cookie Manager对并发的每一个线程是独享cookie的。从官网上有如下一段话可以得到印证：

翻译一下：HTTP Cookie Manager第一个功能是如同浏览器一样存储并发送cookies。当HTTP请求和返回包含cookie时，Cookie Manager自动存储cookie，并在后续发往该网站的请求中携带出去。每一个JMeter线程拥有自己的“cookie 存储区”。所以，如果测试的网站使用cookie进行session信息的存储，则每个JMeter线程都有自己的session。注意，这种cookies在Cookie Manager中是不显示的（就是不用配置的意思），但是可以在View Results Tree监听器中查看到。

第二个功能是，可以在Cookie Manager中手工配置一个cookie。这样全部的JMeter线程会共享该cookie。值得注意的是，这样设置的cookies会在未来一段时间内失效。

6 解答疑虑

疑虑都消除了，可以落实问题了：

1、JMeter并发时，使用同一用户服务器是一个session还是多个session？

如果服务器不做特殊处理（终端唯一判断），是多个session。

2、JMeter使用同一用户并发对服务器是否起到了压测的作用？

如果维持多个session，起到了压测的作用。

3、JMeter使用同一用户并发和不同用户并发有什么区别呢？

相同用户如果能维持多个session，并发的效果是达到的。但是从数据库和中间件缓存来看，会存在命中率的差别。不同数据压测出现缓存无法命中，压力是比同一用户大的，所以建议使用不同用户，更符合真实的场景。

看完本文有收获？请分享给更多人

关注水滴测试，不知不觉变大牛