打破砂鍋看原理，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，並發的效果是達到的。但是從資料庫和中間件緩存來看，會存在命中率的差別。不同數據壓測出現緩存無法命中，壓力是比同一用戶大的，所以建議使用不同用戶，更符合真實的場景。