序：本案例來自我工作中的真實案例，但排查時間之長，涉及人員之多讓我感慨，怎樣才能成為一個能暢遊知識大海的優秀測試工程師。

SAS

本案例是公司的一個與搜尋服務相關的功能介面，為了不涉及公司隱私，我會忽略一些細節，在此簡稱SAS。

網路拓撲

上圖中的網路拓撲圖共分三層，粗略描述了這部分服務所處的網路環境架構：

• Load Balance層: 會從收發請求資訊，將請求資訊按照一定規則傳遞給下層Gateway;
• Gateway層: 服務閘道器，收到上層請求後傳遞給下層的應用伺服器叢集，並接收響應向上層傳送；
• Application Servers: SAS應用服務所在層級，進行業務處理的，並返回結果向上層傳送；

測試場景

• 20，100 Virtual User/ 10 min

• 鏈路測試實驗，分別施加壓力在圖中三層；

• 測試方法：

  • 從Application Server層中挑選一臺機器
  • 從Gateway中挑選一臺伺服器，使其連線Application Server層中的所有伺服器（在執行時有不規範，最初該層並未測試）
  • 從Load Balance中挑選一臺伺服器，使其連線Gateway層中的所有伺服器
  • 測試順序，由下往上依次完成；

測試目的

• 掌握鏈路上每層節點的效能資料，建立基線；
• 保證鏈路上的每一層上，在較大負載時能有良好的表現，儘量減小每一層傳輸所造成的效能損耗；
• 效能水平能夠達到需求規定；

執行測試

發現問題

在20， 100 User的壓力下：

• 在Application Server的測試非常順利，圖形和資料都很優秀。

• 但是從Load Balance層施壓100 User壓力，就可以看到大相徑庭的圖形，如下：

  
  
  

  sas_phenomenon.png
  
  
  

  sas_phenomenon_zoom_in.png
  
  

  圖中標出的兩組測試圖形差異極大，後者的表現只能用不合格來形容。

• 而且蹊蹺的一點是在20 user的小壓力下，這兩層所表現的圖形還是比較穩定的，只是load balance層上的效能略微差一些。按照經驗來說，從最高層往下壓測，效能的穩定性應該還是不錯的。頭一回遇到這種情況，當時就懵了，看來這次測試是無法通過了。

排查思路

• 先檢視測試報告，上個圖：

  
  
  

  sas_phenomenon_error_report.png
• 報告中報錯最多的就是Non HTTP Response code，這種錯誤佔比很高，關於這個問題，我在另外一篇文章JMeter-failed to respond Connection reset問題 中已經有詳細的分析，此處不再贅述。但從現象上來看，似乎是和網路傳輸有一定的關係；
• 反覆對比測試，現象依然存在。。。。

漫漫分析之路

分析：由於在Application Server端，並沒有出現不穩定的情況。而在LoadBalance端出現的極其不穩定，那麼似乎應該是由Load Balance或者Gateway產生的問題

因此，
嫌疑1：Gateway上面的部署的監控SAS服務的追蹤日誌。
測試結果：開啟和關閉日誌，其效能差異微乎其微，在Load Balance端的壓測的結果依然不好；

嫌疑2：Gateway服務叢集是否有可能存在某些臺伺服器的效能出了問題。這個問題，在我以前的測試中是遇到過，也就是說某些伺服器是否拖了後腿。
測試結果：花了兩天排查了所有的Gateway Server，不存在拖後腿的問題；

嫌疑3：既然Gateway叢集已經洗清嫌疑，那麼焦點似乎就集中到了Load Balance上了。當時的Load Balance有兩種服務軟體，Netscaler和Haproxy。在測試前就制定了計劃，其主要目的是確認：

• 是否在效能上這兩種服務存在效能差異？
• 如果有差異，是否是配置造成的？
• 這些Load Balance連線單臺和連線多臺Gateway伺服器後的效能表現如何？

測試結果：

• 效能上兩者存在一定的效能差異，但是差距不大且表現的都不穩定；
• 協同運維工程師的合作，對存在可能問題的配置點進行了調整，但是沒有明顯效果；
• 但發現一個特點，無論是NetScaler或者是Haproxy，連線的Gateway Server數量越少，其效能表現就越穩定；反之，則越糟糕；

這個結果還不算最糟糕的，因為線上還有很多服務執行在同樣的load balance下已經很多年，但是並沒有發現這種奇怪的現象產生。為此，我還進行了大量的橫向對比測試，發現就是針對這個服務引起的。

曙光初現

• 作為一個技術人員，最無助的時刻就像是我操作著一葉孤舟面在洶湧澎湃的大海中尋找目標。

• 前面的報錯報告中，談到了網路錯誤，這給了我們一些提示；由於我沒有許可權去觀測Haproxy的網路指標，因此運維同事特意搭建了一臺臨時的伺服器，並在上面安裝了netdata這個小工具。從這個影像上面，我們看到了網路對比情況：
  

  首先是SAS服務的網路狀況
  

  perf_haproxy_netstat_sas.png
  
  接著是其它服務網路狀況
  

  perf_haproxy_netstat_otherservice.png
  
  

  從中可以看到SAS的網路影像是很雜亂的，似乎是tcp的連線關閉頻繁，導致影像很雜亂；而下圖中其它服務所對應的網路圖形已經近似一個方形很有規律，tcp的建立的連線複用率較高。

這時，開發也提供了一個資訊，這次的服務使用的是tomcat 8，而以往都是使用的tomcat 7。一切的疑點又回到了原點，最初認為問題出在Load Balance層面，繞了一圈又回到了這個服務本身。常常感嘆人生無常，沒想到技術上也是如此。。。

Tomcat 7 vs Tomcat 8

首先宣告，這裡不會涉及兩個web容器版本的不同。而只針對我們公司的服務應用場景，所展示出來的兩者效能差異；
檢視它們的tcp網路圖：
20 user /10 min

100 user / 10 min

效能計數器圖：

乘勝追擊

拿出了鐵一般證據後，線上開始將SAS服務逐步配置tomcat 7。再從Load balance施加壓力，就發現，效能圖形已經很穩定，且吞吐量符合要求。

後續

• 實際上疑點並沒有完全解除，雖然知道了tomcat 7和8在該應用場景上的效能穩定性差距很大，但是並不能說明是tomcat 8的問題；應該說，產生這種差距最可能的原因還是在容器的配置上的差異導致。但遺憾的是，目前開發人員並沒有時間去研究其中的差異。但經歷了這個案例，我還是想繼續追蹤下去，有新訊息我會更新；
• 我對TCP/IP並不熟悉，當探測到了網路丟包，tcp連線不能服用等原因後，還是欠缺從這方面下手找原因的方法和手段。從一個側面也告訴你，每一個問題，都是對你的一個考題，知識越豐富，才越能體現你的價值；
• 雖然這篇文章不長，但是從現象到分析出問題的點，卻花費了很長時間。這過程是很煎熬的，一方面不想放棄找到原因，另一方面，協助我的同事還忙於其他事物，儘管他們對這個問題很有興趣，但時間一長，他們也產生了倦怠。此時，我只能硬著頭皮去激勵他們繼續與我合作，在我意志開始動搖的之前。
• 寫出此文的目的，是為了釐清處理問題的思路，為我今後的工作積累經驗。另外就是一些烏托邦式的成就感，當然這不會改變領導對測試人員的價值看法，價值幾何？也許還不夠加個雞腿吧。。。