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

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

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

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

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

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

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

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

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

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