這些年，我的軟件性能測試

很早之前就說好好總結一下自己的職業，一直忙于一些亂七八糟的事，現在這個時間難得偷得空閑，趁著有感覺，趕緊進行敲下“這些年，我的軟件性能測試”來祭奠我這IT行業的幾年......

　　記得第一次做性能測試項目，心情是忐忑的，覺得，性能測試，做不好就背包滾蛋了都可能，不過當時帶我做項目的老大給了我很大的信心和支撐，我在做的過程中，遇到的疑問，他都會耐心的給我以解答或者給我一個方向，讓我去前行，解決，隨著一個個問題的出現和解決，自己每一天也過的感覺很充實。也是在這個項目里面，這個老大告訴我，作為性能測試，如果僅僅只會用工具，這個只能算初級性能測試工程師，重要的還是設計能力，思想為王，于是，我從他口里聽到了一個詞：性能建模和容量規劃......當時，我真心的不知道這個是什么，有的就是對老大的崇拜和對未來的路如何走的思考......

　　第一個性能項目，如期完成，對google的GA插入的js代碼進行測試，驗證該js注入website之后，對性能的影響（因本身js需要做下載和數據上報，中間的過程需要看下情況如何），測試過程中，發現會有大部分的用戶響應時間比較長，當時就是按照2-5-10法則來做的響應時間是否合理（想想，這個就是傳說中的拍腦袋吧呵呵），想到該如何分析是哪里原因呢？第一次做性能測試，看到結果之后，欣喜的同時更多的是一種忐忑，不知道對著面前的report該如何下手？好在，有老大給予指導，分析了帶寬，排除帶寬的影響，查看server本身的資源，也無問題，同時細分驗證，發現大部分的時間是消耗在server層，于是基于此基礎，直接看了下apache（當時我們用的server）的隊列等待（當時用的方法很簡單，直接ps -ef|grep httpd|wc -l），發現隨著虛擬用戶的逐步增多，會造成排隊的數也越來越多，初步懷疑是配置問題，咨詢了運維，apache 的配置沒有動，用的默認的配置方式，于是我們提出，需要查看并嘗試調整該配置文件。在查看的過程中，參考網上朋友的資源，發現maxclient的確是默認的，修改之后，進行重啟，回歸，發現問題還是存在，，，難道是別的地方慢？怎么弄呢？這個時候運維告訴我們，apache只修改這個還不夠，還需要修改一個隱藏變量，serverlimit，只有修改了它，maxclient修改超過1000的時候才會生效。于是也是瞎子摸象，動手試一試，發現，果真是這里，修改了之后，排隊的用戶減少了，超過5S以上響應時間的用戶百分比也降低，于是開始準備性能測試報告（報告寫了我十多次才發出去，那個苦啊～～～），順便給予運維建議，因當時這一服務對應的apache是單點，建議去除單點，再申請一臺機器作為熱備，高峰時還可作為balance功能使用。于是，我的第一次性能測試，隨著這第一份性能測試報告的發出，結束了.......也從此，我開始踏上了性能測試的路，開始愛上了性能測試

　　在后面的工作中，大大小小的項目也接觸了一些，零零散散的一些性能問題也跟研發，DBA一起定位，調優解決了，但是慢慢的我在思考，性能測試就是這樣了嗎？在隨后而來的一次項目中，讓我知道，其實性能測試并不如此，遠非我之前看到的，之前看到的還不夠深入......

　　記得那次項目，是對c++開發的一個搜索服務server的測試，在測試的過程中，發現，開始沒多久，磁盤就速度變大，內存也消耗的很快，cpu飆的特別快......可并發用戶才5啊，，，，這個問題會在哪里呢？cpu飆的特別快，那一般是運算復雜，調度頻繁，切換頻繁等原因造成的，于是，找到研發，咨詢相關的算法，是否過于復雜，可否再優化？研發也好溝通，給耐心的講解了算法，并回復，當前無法再優化，只能后面逐步來看。那難道就這樣放出去？反正公司不差服務器，堆服務器就是了，硬件解決性能問題似乎成了行業的潛規則，而且產品也說了，平常根本也沒多少人會用這個，這樣的問題，他們也可以接受......就這樣發到外網？不，作為一名性能測試工程師，如果就這樣洗洗睡了，那我們的價值在哪里？于是，跟研發建議，如果確實是算法的問題，在當前我們無法進行修改，調優的基礎上，是否可以進一步請求資深和專家研發給予check和給予建議，對該風險進行分析？于是，研發開始進一步確認到底是算法哪一塊，哪一處消耗最多，戲劇的是，分析到最后，發現該問題并不是算法是主要兇手，之前冤枉了算法，而是程序本身的一個bug，研發之前對于c++里面用到的hashtable，錯誤的認為是有序的，但實際該hashtable在處理的時候是無序的，從而造成每次都會生成新的追加的文件，這樣文件越來越大，造成磁盤瘋狂的長，同時寫磁盤這個過程對cpu的占用也就飆的很高，再一個，讀數據的時候，之前都是直接很疼的從磁盤上拿，沒有做map處理，map處理之后使得程序都從內存里面讀，這樣響應時間也得到了有效的提升，并且，研發還對不該加鎖的地方進行了順序讀的鎖處理進行修復，導致server的吞吐率得到提升......最終，版本打回研發，研發自測后，再進行提測和驗證

　　在上個項目中，讓我覺得，作為一名性能測試工程師，不要錯誤的將自己定義為架構師（很多行業的人都覺得性能測試工程師很牛逼，牛逼的過程中，不自然間就把這個職位等價成了架構師，其實我想說，架構師是高于性能測試工程師的），但是，一名優秀的性能測試工程師應該不斷的靠近架構師，只有這樣，才能真正的從根本上去發現，解決問題，才能在研發體系中更好的體現自己的價值.也在這個項目之后，我開始思考并有了后面我主導的一個虛擬項目，“BMW軟件性能平臺”（據說名字霸氣點是好事：））......

　　另：這些年的項目經驗，還讓我認識到，對于有的性能問題，在調優的時候，并不是說就一定需要用技術解決的，有的問題，技術不能解決的，需要思考和嘗試業務需求上的調整，有的性能問題的定位和分析，并不是說就一定要那么費勁周折，高并發，查這里，看那里來定位和解決，有的只用單個用戶，發個請求，抓個包，看下timechart，看下代碼構成，就可以解決了.性能測試，我一直堅持，它跟監控是離不開的，有了監控，有了數據準備和數據收集，我們才能更快更好的發現問題，分析和解決問題（這個也是我弄“BMW軟件性能平臺”的原因）

　　這些年，我的軟件性能測試項目經驗，讓我獲得了很多，也失去了很多，對于行業的認識也看的更加深入了些，開始接觸并學習之前根本不知道的語言內核知識，TCP/IP原理等網絡知識，深深的感覺到學海無涯，而吾身有涯......

　　這些年，我的軟件性能測試，寫在我即將逝去的28歲......