對於應用壓測大家應該都有一些自己的方式，通常都是構造一些請求，不過構造請求學問就大了。
構造什麼樣的請求？構造的請求是否真實？構造的請求各種業務場景的配比？讀寫比例？
對於乙個web瀏覽型應用來說，相比對純db的壓測，會更複雜一些，主要因為涉及快取。
之前採用過很多壓測方式，包括ab、httpload等等，這些壓測方式的缺點在於無法真實反映乙個瀏覽型系統的效能指標。和其它對db的查詢或是呼叫外部服務的應用不同，瀏覽型系統在大量採用cache和存在命中率的前提下，命中cache和不命中的效能差距非常大。
如果按悲觀的角度，從完全不命中的角度考慮，那麼單機的能力會很低，相應的需要增加非常多的機器，而如果把命中率估得很高，又顯得太樂觀。還有另外乙個比較頭疼的問題是，即使你知道自己的命中率是多少，你也無法僅僅按百分比去計算你的qps能力，因為有可能你的命中以外還有額外的開銷，並不是記憶體直接返回的，例如各種esi。你還需要準確地計算出這些消耗的型別以及它們各自的佔比、耗時，最後會被圍困在乙個存在各種不確定性因素的牢籠中。
最悲催的情況就是你用乙個url去壓測，壓出來乙個非常好的效能，然後上線時發現單機根本達不到這個效能指標，只能臨時去加機器緩解。
於是我就在思考，如何擺脫之前那些不確定性因素，我們不去猜測命中率、qps這些指標，能否通過更真實的線上請求來做？
事實是當然可以，我們隨機選取一些機器，通過tcp包拷貝的方式直接將真實請求**到一台機器處理，做到了真實場景下的壓測。
這種壓測的效果還是不錯的，沒再壓出不靠譜的那麼虛高的指標，回歸大地，回歸真實。
事實上當我們把單機qps壓到之前出問題的量級時，確實復現了當時的情況，這也進一步證實了這種壓測方式是靠譜、真實的。
需要注意的是你需要注意自己的cache範圍，本機cache還好，如果是分布式cache，所有機器共享的，那麼需要保證被壓測機器訪問的cache和其它機器要分開，否則被壓機器的cache永遠是命中的。
easy runner乙個簡單的壓測程式
這次再公開乙個小工具easy runner乙個來用做壓測的小工具 我主要用來做mysql壓測的時候,直接壓業務端用的.程式很簡單,總共不到400來行,推薦程式設計師自己壓測用,比loadrunner這種重型壓測工具使用起來方便多了 使用說明見 戶端要求較高,不能有太多的執行緒數 見easy runn...
如何測乙個紙杯 如何測試乙個紙杯
測試專家 請測試乙個紙杯?測試菜鳥 什麼?測試專家 如果給你乙個喝水的一次性一次紙杯，你將如何測試它?測試菜鳥 我想想啊。幾分鐘後。測試菜鳥 倒滿水看看漏不漏。嗯。測試專家 還有麼?測試菜鳥 能不能倒出水來。會不會變形?乙個紙杯怎麼測啊?腦子全亂了?哦，對了 你有需求麼?測試專家 嗯，不錯的問題，你...
mysql簡單壓測 運了乙個維
mysqlslap options 常用引數 options 詳細說明 auto generate sql,a 自動生成測試表和資料，表示用mysqlslap工具自己生成的sql指令碼來測試併發壓力。auto generate sql load type type 測試語句的型別。代表要測試的環境是...