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

SAS

本案例是公司的一個(gè)與搜索服務(wù)相關(guān)的功能接口，為了不涉及公司隱私，我會(huì)忽略一些細(xì)節(jié)，在此簡稱SAS。

網(wǎng)絡(luò)拓?fù)?/h1>

network_topology_sas.png

上圖中的網(wǎng)絡(luò)拓?fù)鋱D共分三層，粗略描述了這部分服務(wù)所處的網(wǎng)絡(luò)環(huán)境架構(gòu)：

• Load Balance層: 會(huì)從收發(fā)請求信息，將請求信息按照一定規(guī)則傳遞給下層Gateway;
• Gateway層: 服務(wù)網(wǎng)關(guān)，收到上層請求后傳遞給下層的應(yīng)用服務(wù)器集群，并接收響應(yīng)向上層傳送；
• Application Servers: SAS應(yīng)用服務(wù)所在層級(jí)，進(jìn)行業(yè)務(wù)處理的，并返回結(jié)果向上層傳送；

測試場景

• 20，100 Virtual User/ 10 min

• 鏈路測試實(shí)驗(yàn)，分別施加壓力在圖中三層；

• 測試方法：

  • 從Application Server層中挑選一臺(tái)機(jī)器
  • 從Gateway中挑選一臺(tái)服務(wù)器，使其連接Application Server層中的所有服務(wù)器（在執(zhí)行時(shí)有不規(guī)范，最初該層并未測試）
  • 從Load Balance中挑選一臺(tái)服務(wù)器，使其連接Gateway層中的所有服務(wù)器
  • 測試順序，由下往上依次完成；

測試目的

• 掌握鏈路上每層節(jié)點(diǎn)的性能數(shù)據(jù)，建立基線；
• 保證鏈路上的每一層上，在較大負(fù)載時(shí)能有良好的表現(xiàn)，盡量減小每一層傳輸所造成的性能損耗；
• 性能水平能夠達(dá)到需求規(guī)定；

執(zhí)行測試

發(fā)現(xiàn)問題

在20， 100 User的壓力下：

• 在Application Server的測試非常順利，圖形和數(shù)據(jù)都很優(yōu)秀。

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

  
  
  sas_phenomenon.png
  
  
  sas_phenomenon_zoom_in.png
  
  

  圖中標(biāo)出的兩組測試圖形差異極大，后者的表現(xiàn)只能用不合格來形容。

• 而且蹊蹺的一點(diǎn)是在20 user的小壓力下，這兩層所表現(xiàn)的圖形還是比較穩(wěn)定的，只是load balance層上的性能略微差一些。按照經(jīng)驗(yàn)來說，從最高層往下壓測，性能的穩(wěn)定性應(yīng)該還是不錯(cuò)的。頭一回遇到這種情況，當(dāng)時(shí)就懵了，看來這次測試是無法通過了。

排查思路

• 先查看測試報(bào)告，上個(gè)圖：

  
  
  sas_phenomenon_error_report.png
• 報(bào)告中報(bào)錯(cuò)最多的就是Non HTTP Response code，這種錯(cuò)誤占比很高，關(guān)于這個(gè)問題，我在另外一篇文章JMeter-failed to respond Connection reset問題 中已經(jīng)有詳細(xì)的分析，此處不再贅述。但從現(xiàn)象上來看，似乎是和網(wǎng)絡(luò)傳輸有一定的關(guān)系；
• 反復(fù)對比測試，現(xiàn)象依然存在。。。。

漫漫分析之路

分析：由于在Application Server端，并沒有出現(xiàn)不穩(wěn)定的情況。而在LoadBalance端出現(xiàn)的極其不穩(wěn)定，那么似乎應(yīng)該是由Load Balance或者Gateway產(chǎn)生的問題

因此，
嫌疑1：Gateway上面的部署的監(jiān)控SAS服務(wù)的追蹤日志。
測試結(jié)果：打開和關(guān)閉日志，其性能差異微乎其微，在Load Balance端的壓測的結(jié)果依然不好；

嫌疑2：Gateway服務(wù)集群是否有可能存在某些臺(tái)服務(wù)器的性能出了問題。這個(gè)問題，在我以前的測試中是遇到過，也就是說某些服務(wù)器是否拖了后腿。
測試結(jié)果：花了兩天排查了所有的Gateway Server，不存在拖后腿的問題；

嫌疑3：既然Gateway集群已經(jīng)洗清嫌疑，那么焦點(diǎn)似乎就集中到了Load Balance上了。當(dāng)時(shí)的Load Balance有兩種服務(wù)軟件，Netscaler和Haproxy。在測試前就制定了計(jì)劃，其主要目的是確認(rèn)：

• 是否在性能上這兩種服務(wù)存在性能差異？
• 如果有差異，是否是配置造成的？
• 這些Load Balance連接單臺(tái)和連接多臺(tái)Gateway服務(wù)器后的性能表現(xiàn)如何？

測試結(jié)果：

• 性能上兩者存在一定的性能差異，但是差距不大且表現(xiàn)的都不穩(wěn)定；
• 協(xié)同運(yùn)維工程師的合作，對存在可能問題的配置點(diǎn)進(jìn)行了調(diào)整，但是沒有明顯效果；
• 但發(fā)現(xiàn)一個(gè)特點(diǎn)，無論是NetScaler或者是Haproxy，連接的Gateway Server數(shù)量越少，其性能表現(xiàn)就越穩(wěn)定；反之，則越糟糕；

這個(gè)結(jié)果還不算最糟糕的，因?yàn)榫€上還有很多服務(wù)運(yùn)行在同樣的load balance下已經(jīng)很多年，但是并沒有發(fā)現(xiàn)這種奇怪的現(xiàn)象產(chǎn)生。為此，我還進(jìn)行了大量的橫向?qū)Ρ葴y試，發(fā)現(xiàn)就是針對這個(gè)服務(wù)引起的。

曙光初現(xiàn)

• 作為一個(gè)技術(shù)人員，最無助的時(shí)刻就像是我操作著一葉孤舟面在洶涌澎湃的大海中尋找目標(biāo)。

• 前面的報(bào)錯(cuò)報(bào)告中，談到了網(wǎng)絡(luò)錯(cuò)誤，這給了我們一些提示；由于我沒有權(quán)限去觀測Haproxy的網(wǎng)絡(luò)指標(biāo)，因此運(yùn)維同事特意搭建了一臺(tái)臨時(shí)的服務(wù)器，并在上面安裝了netdata這個(gè)小工具。從這個(gè)圖像上面，我們看到了網(wǎng)絡(luò)對比情況：
  

  首先是SAS服務(wù)的網(wǎng)絡(luò)狀況
  perf_haproxy_netstat_sas.png
  
  接著是其它服務(wù)網(wǎng)絡(luò)狀況
  perf_haproxy_netstat_otherservice.png
  
  

  從中可以看到SAS的網(wǎng)絡(luò)圖像是很雜亂的，似乎是tcp的連接關(guān)閉頻繁，導(dǎo)致圖像很雜亂；而下圖中其它服務(wù)所對應(yīng)的網(wǎng)絡(luò)圖形已經(jīng)近似一個(gè)方形很有規(guī)律，tcp的建立的連接復(fù)用率較高。

這時(shí)，開發(fā)也提供了一個(gè)信息，這次的服務(wù)使用的是tomcat 8，而以往都是使用的tomcat 7。一切的疑點(diǎn)又回到了原點(diǎn)，最初認(rèn)為問題出在Load Balance層面，繞了一圈又回到了這個(gè)服務(wù)本身。常常感嘆人生無常，沒想到技術(shù)上也是如此。。。

Tomcat 7 vs Tomcat 8

首先聲明，這里不會(huì)涉及兩個(gè)web容器版本的不同。而只針對我們公司的服務(wù)應(yīng)用場景，所展示出來的兩者性能差異；
查看它們的tcp網(wǎng)絡(luò)圖：
20 user /10 min

tomcat7_20user.jpg

tomcat8_20user.jpg

100 user / 10 min

tomcat7_100user.jpg

tomcat8_100user.jpg

性能計(jì)數(shù)器圖：

tomcat7_vs_8_perfconter.jpg

乘勝追擊

拿出了鐵一般證據(jù)后，線上開始將SAS服務(wù)逐步配置tomcat 7。再從Load balance施加壓力，就發(fā)現(xiàn)，性能圖形已經(jīng)很穩(wěn)定，且吞吐量符合要求。

change_to_tomcat7.jpg

后續(xù)

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