壓力測試及調優記錄

零零星星記錄

=============

場景一：

環境：web服務器2核2.5G一臺；數據庫mysql：600最大鏈接數，2400M內存。 壓測的應用：普通門戶網站，lamp軟件環境。

壓測工具:loadrunner模擬真實用戶訪問行爲

模擬動做: 進入首頁- 進入」當即使用」頁面- 查看掌櫃活動頁面思考時間總共15秒

即完成3個頁面的訪問;

測試方法: 模擬100個用戶每5秒登陸2個,(2分鐘加載完畢)

持續1小時, 總時間1小時13分鐘重複完成模擬動做;

測試結果: 平均響應時間各頁面均<2秒;

其中83%的用戶響應時間在3秒內;   90%的用戶響應時間在3.8秒內;

總共完成21304個用戶的模擬動做, 訪問頁面數總次數  21304*3= 63912次

服務器端基本正常, 負載值 2.5左右;

壓力測試過程當中不斷加壓相關參數調整：

apache優化調整：

serverlimit 5500 默認maxclient最大線程256個，可設置更高。

maxclients 5000 限制同一時間客戶端最大接入請求的數量。

MaxRequestPerChild 100 每一個子進程在其生存期內容許同的最大請求量，也即一個鏈接進程中能夠有多少個線程同時工做。

最終結果：

網易郵箱理論單日收發郵件是 1000 封,

在模擬100用戶併發狀態下 15分鐘內成功收取近980封郵件,

其餘近1000封郵件在後續的1.5小時內陸續收取完成;

當日總共完成3000封左右的郵件收發.

調優後的網站每小時支持2萬左右的用戶訪問數, 6萬左右的單頁面訪問次數 (服務端無壓力)。此壓測行爲基本不涉及至數據庫。

場景二：

web服務器4核4G兩臺；數據庫mysql：600最大鏈接數，2400M內存。 壓測的應用：saas軟件雲平臺.

apache+tomcat+memcached+mysql環境。

壓測工具:loadrunner模擬真實用戶訪問行爲。

壓力測試過程當中不斷加壓相關參數優化調整：

1）tomcat配置優化調整：

maxthreads 最多同時處理N個鏈接（啓動的最大線程數，設置800）

acceptcount 當同時鏈接的人數達到maxthreads時，還能夠接收排隊的鏈接，設置10000

maxprocessors 最大鏈接線程數，即併發處理的最大請求數，設置1000

2）jvm優化調整：

JAVA_OPTS="$JAVA_OPTS -Djava.awt.headless=true -server -Xmx2500m -Xms2500m -Xmn1200m -XX:SurvivorRatio=8 -XX:PermSize=128m -XX:MaxPermSize=256m -Xss128k -XX:

MaxTenuringThreshold=7 -XX:ParallelGCThreads=2 -XX:GCTimeRatio=19 -Xnoclassgc -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+CMSPermGenSweepingEnabled -XX:+Us

eCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0 -XX:CMSInitiatingOccupancyFraction=70 -XX:+PrintClassHistogram -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintGCApplicationConcurrentTime -XX:+PrintGCApplicationStoppedTime -XX:+PrintTenuringDistribution -Xloggc:/home/saas/apache-tomcat-6.0.36/logs/tomcat_gc.log -Doracle.jdbc.V8Compatible=true"

最終結果：每秒承受最大併發6個用戶，主要壓力瓶頸在數據庫上。