系統部署到正式伺服器上，要做壓力測試。
昨天在單位壓200個使用者併發，到160多個後，出現大量的連線超時。結果就是通不過200個併發使用者。關了loadrunner,訪問系統，系統已經訪問不了。晚上回來訪問還是無法訪問。今天一早打算去機房看看，去之前再訪問系統，竟然能訪問，速度還不錯。
到了機房，連線上伺服器一看日誌，昨天有outofmemory，重啟了系統，在機房現場壓，同樣，併發訪問到140個使用者之後，系統就會出現大量超時，訪問失敗。
修改mysql最大連線數到100000，tomcat最大使用者數到5000，重啟系統，再壓一次，最多到160，系統就不行了。開啟jconsole，報了好多socketerror。
我們系統併發訪問量小，技術上原因，做到**那種千萬百萬級別的併發訪問並不現實，可是理論上應該併發400沒問題，所以一定是某個地方出了問題了。
看了拓撲圖，外網訪問應用伺服器，要經過一道防火牆，應用伺服器連線資料庫伺服器又要經過一道防火牆，所以判斷有可能是防火牆的問題。
於是在應用伺服器上裝了資料庫，改連本機的資料庫，重新啟動後。同時併發200個使用者很順利，2分鐘搞定，tomcat記憶體占用也不多，不到1個g。300個也很快。只是後來到了390個後，開始報連線超時，此時記憶體占用是1.9個g。390個併發使用者可以基本滿足要求了。
看來確實是防火牆的問題，請求被第二道防火牆攔截。明天去了請防火牆廠商的人修改下引數。同時，我再試試加大tomcat記憶體，使併發數再大一些。好像今天修改tomcat記憶體，最大就到2g。
Apache Bench做壓力測試
apache bench是乙個簡單易用的壓力測試工具，在這裡我不想多講。今天主要說的是寫乙個py指令碼來自動化測試過程，以及中間遇到的一些奇葩問題。python usr bin env python encoding utf 8 import sys import subprocess as sub...
jmeter badboy做壓力測試
前段時間公司有個投票，當時我還不會用jmeter，只是用自動化一次次的執行，結果排名非常靠後，想想是個chiru啊。如下過程參考鏈結 壓力測試之badboy和jmeter的簡單使用方法 現在先做個簡單的，badboy錄製 1，輸入 點選後面的向右箭頭 jmeter上場 jmeter可以使用剛才bad...
使用apacheBench做壓力測試
乙個簡單的例子 在這個例子的一開始，我執行了這樣乙個命令ab n 10 c 10這個命令的意思是啟動 ab 向 www.google.com 傳送10個請求 n 10 並每次傳送10個請求 c 10 也就是說一次都發過去了。跟著下面的是 ab 輸出的測試報告，紅色部分是我新增的注釋。整個測試持續的時...