一、編寫目的
本文檔從性能工程的角度提出開展性能測試工作的流程，和進行性能測試工作的策略，以及針對promotion的性能測試方法指導；主要討論性能測試的需求階段、確立目標、設計階段、用力場景設計、監控資源，和針對promotion項目的性能測試指南。
二、需求階段
性能測試需求的來源
性能測試需求的來源有三個方面：
1、 需求文檔
2、 設計文檔
3、 客戶備忘錄
確定性能測試需求的解決方法
在沒有需求文檔和設計文檔的情況下，我們需要對TSP系統上的客戶業務使用情況進行分析，提出我們所關注的性能測試需求，並告知業務人員。讓業務人員來判斷我們的性能需求是否能滿足客戶的真實要求。
在通過TSP系統分析業務使用狀況時，我們可以從以下方面來關注：
1、確定當前系統的業務使用狀況：通過TSP的日誌記錄－客戶端模塊使用情況瞭解在某個時間段內，客戶執行某個操作的具體情況。
2、瞭解不同視角的用戶性能：
ⅰ）用戶視角：
響應時間：用戶所能感受到的響應時間，也是用戶最重視的性能體驗。
確立響應時間的原則：2/5/10原則
2：2秒鐘用戶會覺得是一個很好的體驗。
5：5秒鐘用戶可能會覺得差了一點，還行，比較好。
10：10秒鐘是用戶所能承受的最大極限。
鑑於不同地區的網絡環境，將用戶所能承受的響應時間極限定爲12～15秒。
此部分需與業務人員討論。
穩定性：系統長時間運行不會出現錯誤的能力。
驗證方法：系統在滿負載的運行8小時，系統是否會出現服務不可用，Connection Refused
HTTP 404,500錯誤。
ⅱ）系統視角：延遲，系統資源使用狀況
延遲：包括數據庫延遲和網絡延遲
此部分需與DBA及系統部人員討論。
系統資源使用狀況：服務器的CPU使用率是否長期高於80％，達到90％，100％的程度，整個磁盤的I/O是否達到極限。內存的使用數是否只剩下極少的幾兆，幾十兆。
ⅲ）開發者視角：從代碼實現和數據庫實現來考慮性能。看看這兩方面得到實現是否足夠好。
3、瞭解真正的性能測試需求
方法：ⅰ）識別項目干係人：指的是和項目相關的人，開發人員，設計人員，需求人員，業務人員，上層領導，瞭解他們對性能測試的考慮。
ⅱ）隱藏在“性能測試”之後的實際想法，比如：是因爲開發人員對所完成的代碼沒有信心，又不願意做修改，要求我們對其所作的程序進行性能測試，還是設計人員使用了一項新技術，心裏沒低，所要求作的性能測試，等等。
三、確立性能測試目標
確立性能測試目標的原則
1、以“需求”爲本
考慮系統需不需要作性能測試，性能測試的內容和範圍。
2、測試目標確定的經濟性考慮
ⅰ）投入到性能測試的人員是多少？
ⅱ）具備可以確定性能測試需求，制定性能測試方案的人員是多少？可以執行性能測試的人員是多少？
ⅲ）這些人員需要投入多長時間？
ⅳ）所要開發系統的運行環境和設備，這些設備的配置對於性能測試的影響，比如說：tomcat4.1的應用服務器，它的配置文件缺省的jvm的使用空間是64M，一個機器的內存爲1G，我們將jvm的使用空間設置爲512M對性能測試的影響。
ⅴ）內部的人員無法滿足性能測試的要求，通過外聘，採用外聘的方式，公司所能承受的成本是多高。
3、基於風險的測試目標確定
ⅰ）系統如果不做性能測試，會有多大的風險，如果在性能指標上達不到用戶的要求會有多大的風險。需要進行評估。
ⅱ）如果做性能測試會有多大的風險，性能測試的投入會有多大，會有多大的風險需要進行評估。
確定性能測試目標的方法
我們要確定系統的吞吐量和併發用戶數的設計目標可以採用以下三種方式：
l 確定在某個特定時間端內，估計系統會有多少用戶同時訪問
l 在某個特定的時間端內，正在訪問系統的用戶的典型操作是什麼？哪個頁面的訪問量最大？
l 在某個特定的時間端內，系統需要處理多少種用戶場景
這些數據可以在系統服務器的日誌文件、TSP監視數據種找到，也可以通過監視數據庫的活動情況來獲得。
四、設計階段
性能測試方案的確立
在確立性能測試方案之前，需要作的工作
1、確定測試目標和需求
這裏的靈活性比較大，與性能測試成敗有很大的關係。
2、瞭解現狀
ⅰ）業務使用狀況
通過日誌記錄，在某個時間段內，用戶的操作。
ⅱ）瞭解環境：包括網絡條件，服務器條件，軟硬件條件，應用服務器環境及各種配置信息。
3、確定需要監控的指標：
ⅰ）CPU使用率
ⅱ）內存使用情況
在此應優先監控應用服務器的性能指標。對於Tomcat或者Weblogic來說，監控他的JVM使用狀況，連接池的連接數量，內存使用狀況等信息。對於數據庫來說監控cache的命中率，索引的使用狀況，數據庫的連接數。
五、用例和場景設計
用例和場景設計的步驟：
1、對業務的分析和分解
2、根據業務確定用例
3、不同用例按照不同的發生比例組成場景
4、瞭解每個場景的實際意義（對場景執行測試，收集結果）
瞭解業務的分佈情況，根據業務確定用例，在設計用例的時候，根據前期收集的數據，設計不同的場景來組成用例，並瞭解每個場景的實際意義，執行場景，收集結果數據。
場景設計的例子（主要是根據業務的使用狀況）：
l 場景1：10％登錄，10％入庫，30％訂單，20％出庫，30％查詢（1000用戶）——日常
l 場景2：10％登錄，90％查詢（400用戶）——週末盤點
六、設定需要監控的資源
設定需要監控的資源主要有一下幾個方面：
1、CPU利用率
2、內存使用情況
3、數據庫監控
4、JVM使用狀況監控
應優先監控應用服務器的性能指標。對於Tomcat或者Weblogic來說，監控他的JVM使用狀況，連接池的連接數量，內存使用狀況等信息。對於數據庫來說，cache的命中率，索引的使用狀況，數據庫的連接數，具體的監控指標請性能測試工程師，根據性能需求確定。
七、Promotion 性能測試指南
本文主要是描寫針對Media Promotion營銷系統各個功能進行性能測試的基本方法。
Media Promotion營銷系統能讓運營商簡單方便地進行內容營銷（包括彩鈴、振鈴、全曲、視頻）。系統能夠根據營銷任務定期向目標用戶羣組發送營銷短信、彩信或郵件，用戶還可以根據需要在系統中配置掛機短信營銷任務和事件觸發短信營銷任務。
測試目標
本次性能測試的目的是驗證Media Promotion營銷系統在大量用戶量情況下，營銷任務的速率符合要求。具體測試方案是通過對羣發短信/彩信的性能測試，觀察系統資源的表現以及各步驟響應時間，以確定Media Promotion營銷系統的性能。
根據使用場景分析，Media Promotion營銷系統中使用頻率比較高的功能主要是：增加羣組、羣發短信、羣發彩信、掛機短信。
系統分析
Media Promotion雙機組網
Media Promotion壓力傳遞
通過壓力傳遞分析，確定潛在瓶頸如下：
1、數據庫的性能：Web頁面向數據庫發出操作請求，數據庫的響應速度將直接影響到Web頁面處理請求的速度。很多後臺處理在存儲過程中實現，壓力也隨之分攤到了數據庫，另外，一些低效的SQL語句，冗餘的表結構等等都會成爲妨礙數據庫應用性能的一個因素，因此數據庫的性能也可能會是影響系統性能的瓶頸。
2、營銷任務處理的性能：在大數據量的情況下，線程掃描任務記錄是否準確並及時發送，以及媒體網關的處理能力可能存在性能瓶頸。
3、接口性能：在大數據量的情況下，接口調用的及時響應時也是影響WEB查詢、營銷任務處理的性能瓶頸。
1 性能環境調優
2 性能環境搭建
參考各版本安裝指導書。
3 性能測試方法
1
2
3
3.1 添加羣組(自定義羣組)
1、流程分析：管理員通過Web頁面創建自定義用戶羣組包括文件導入、添加散列號碼、添加號段，系統根據配置項“子羣組所包含最大的號碼數量”、“全局號段匹配值”，將用戶信息寫入數據庫T_PUSH_GROUPINFO、T_PUSH_SUBGROUPINFO、T_PUSH_GROUPMEMBER表，並操作日誌寫入T_PUSH_BATCH_OPERATION_LOG表。
2、數據構造：
3、資源觀察：
運行時長(秒)、平均每秒入庫(條)、成功數
select (max(t.updatetime) - min(t.updatetime)) * 60 * 60 * 24 column1,
count(*) / ((max(t.updatetime) - min(t.updatetime)) * 60 * 60 * 24) column2,
count(*) column3
from t_push_groupmember t
where groupid in (select groupid
from t_push_groupinfo
where groupname = '創建的羣組名稱')
並行任務時，執行以下語句
select (max(t.updatetime) - min(t.updatetime)) * 60 * 60 * 24 column1,
count(*) /
((max(t.updatetime) - min(t.updatetime)) * 60 * 60 * 24) column2,
count(*) column3
from t_push_groupmember t
where groupid in (select groupid
from t_push_groupinfo
where (groupname = '創建的羣組名稱1' or groupname = '創建的羣組名稱2'))
需要保證創建的羣組名稱不同。
根據實際創建的羣組名稱，替換藍色部分。
僅支持多記錄一次性增加的情況。
CPU佔用(%)
sar -P ALL 2 0 > CPU.txt
"2"表示時間間隔爲2s，"0"表示收集總次數，如果爲0則表示無限次，如果>0則在執行完指定的次數後自動退出；後面的">"符號表示把數據輸出到CPU.txt文件，測試後完成後，我們對CPU.txt文件進行分析即可。
內存佔用(MB)
sar -r 2 0 > MEM.txt
"2"表示時間間隔爲2s，"0"表示收集總次數，如果爲0則表示無限次，如果>0則在執行完指定的次數後自動退出；後面的">"符號表示把數據輸出到MEM.txt文件，測試後完成後，我們對MEM.txt文件進行分析即可。
3.2 羣發短信
1、流程分析：管理員通過Web頁面創建通知類羣發短信營銷任務，保存在數據庫t_push_sendsms表；
系統根據配置項“短信羣發線程數配置”、“營銷任務羣發任務發送時，每臺portal上啓動的發送短信線程數”的線程數，從T_PUSH_GROUPMEMBER表獲取成員號碼，每個線程獲取號碼數量由“子羣組所包含最大的號碼數量”控制；
從t_content_rbtinfo表獲取回覆類歌曲內容；
根據“發送限制方式”、“限制名單”配置，發送線程將數據取到內存，處理完成後將結果寫入t_rule_batchsendsmlog表。
2、數據構造：
3、資源觀察：
發送時長(秒)、發送速率(條/秒)、總髮送數、成功數
select
t1.column1, t1.column2, t1.column3, t2.column4
from ((select
(max(t.time) - min(t.time)) * 60 * 60 * 24 column1,
count(*) / ((max(t.time) - min(t.time)) * 60 * 60 * 24) column2,
count(*) column3
from t_rule_batchsendsmlog t
where smsid = id)
) t1,
(select
count(*) column4
from t_rule_batchsendsmlog t
where smsid = id
and result = 0
) t2;
並行任務時，執行以下語句（時間是最早開始，最晚結束）
select
t1.column1, t1.column2, t1.column3, t2.column4
from ((select
(max(t.time) - min(t.time)) * 60 * 60 * 24 column1,
count(*) / ((max(t.time) - min(t.time)) * 60 * 60 * 24) column2,
count(*) column3
from t_rule_batchsendsmlog t
where (smsid = id1 or smsid = id2)
and t.time >= to_date(' 2011-10-25 18:00:00 ', 'SYYYY-MM-DD HH24:MI:SS')
and t.time <= to_date(' 2011-10-25 20:00:00 ', 'SYYYY-MM-DD HH24:MI:SS')
)
) t1,
(select
count(*) column4
from t_rule_batchsendsmlog t
where (smsid = id1 or smsid = id2)
and result = 0
and t.time >= to_date(' 2011-10-25 18:00:00 ', 'SYYYY-MM-DD HH24:MI:SS')
and t.time <= to_date(' 2011-10-25 20:00:00 ', 'SYYYY-MM-DD HH24:MI:SS')
) t2;
根據實際創建的營銷任務id，替換藍色部分。
根據實際的併發開始時間、結束時間替換替換藍色部分。
僅支持多記錄一次性增加的情況。
CPU佔用(%)
sar -P ALL 2 0 > CPU.txt
"2"表示時間間隔爲2s，"0"表示收集總次數，如果爲0則表示無限次，如果>0則在執行完指定的次數後自動退出；後面的">"符號表示把數據輸出到CPU.txt文件，測試後完成後，我們對CPU.txt文件進行分析即可。
內存佔用(MB)
sar -r 2 0 > MEM.txt
"2"表示時間間隔爲2s，"0"表示收集總次數，如果爲0則表示無限次，如果>0則在執行完指定的次數後自動退出；後面的">"符號表示把數據輸出到MEM.txt文件，測試後完成後，我們對MEM.txt文件進行分析即可。
3.3 羣發彩信
1、流程分析：管理員通過Web頁面創建羣發彩信營銷任務，保存在數據庫t_push_mmstask表。
系統根據配置項“彩信羣發線程數配置”的線程數，從T_PUSH_GROUPMEMBER表獲取成員號碼，每個線程獲取號碼數量由“子羣組所包含最大的號碼數量”控制；
根據“發送限制方式”、彩信內容模板，從“彩信內容文件存放路徑”獲取彩信內容，發送線程將數據取到內存；
處理完成後將結果寫入t_push_logsendmms表。
發送流程圖，與羣發彩信一致。
2、數據構造：
3、資源觀察：
發送時長(秒)、發送速率(條/秒)、總髮送數、成功數
select
t1.column1, t1.column2, t1.column3, t2.column4
from ((select
(max(t.time) - min(t.time)) * 60 * 60 * 24 column1,
count(*) / ((max(t.time) - min(t.time)) * 60 * 60 * 24) column2,
count(*) column3
from t_push_logsendmms t
where mmstaskid = id)
) t1,
(select
count(*) column4
from t_push_logsendmms t
where mmstaskid = id
and result = 0
) t2;
並行任務時，執行以下語句
select
t1.column1, t1.column2, t1.column3, t2.column4
from ((select
(max(t.time) - min(t.time)) * 60 * 60 * 24 column1,
count(*) / ((max(t.time) - min(t.time)) * 60 * 60 * 24) column2,
count(*) column3
from t_push_logsendmms t
where (mmstaskid = id1 or mmstaskid = id2)
and t.time >= to_date(' 2011-10-25 18:00:00 ', 'SYYYY-MM-DD HH24:MI:SS')
and t.time <= to_date(' 2011-10-25 20:00:00 ', 'SYYYY-MM-DD HH24:MI:SS')
)
) t1,
(select
count(*) column4
from t_push_logsendmms t
where (mmstaskid = id1 or mmstaskid = id2)
and result = 0
and t.time >= to_date(' 2011-10-25 18:00:00 ', 'SYYYY-MM-DD HH24:MI:SS')
and t.time <= to_date(' 2011-10-25 20:00:00 ', 'SYYYY-MM-DD HH24:MI:SS')
) t2;
根據實際創建的營銷任務id，替換藍色部分。
根據實際的併發開始時間、結束時間替換替換藍色部分。
僅支持多記錄一次性增加的情況。
CPU佔用(%)
sar -P ALL 2 0 > CPU.txt
"2"表示時間間隔爲2s，"0"表示收集總次數，如果爲0則表示無限次，如果>0則在執行完指定的次數後自動退出；後面的">"符號表示把數據輸出到CPU.txt文件，測試後完成後，我們對CPU.txt文件進行分析即可。
內存佔用(MB)
sar -r 2 0 > MEM.txt
"2"表示時間間隔爲2s，"0"表示收集總次數，如果爲0則表示無限次，如果>0則在執行完指定的次數後自動退出；後面的">"符號表示把數據輸出到MEM.txt文件，測試後完成後，我們對MEM.txt文件進行分析即可。
3.4 掛機短信
1、流程分析：管理員通過Web頁面創建掛機短信營銷任務，保存在數據庫t_push_hangsm表。
系統根據掛機短信ftp配置信息，從ftp服務器獲取掛機話單，並將話單信息保存到數據庫t_push_ds_offlinefileinfo表；
解析話單文件，根據創建的營銷任務，連接USDP數據庫對用戶狀態進行判斷，並根據配置項“創建掛機短信羣組時，一個子羣組所包含最大的號碼數量”將發送記錄保存到t_push_ds_offlinesms_x(x爲1-7的數字)表，對應的羣組信息保存到t_push_ds_offlinegroupinfo_x(x爲1-7的數字)表；
根據配置項“短信羣發線程數配置”的線程數，從t_push_ds_offlinesms_x(x爲1-7的數字)表獲取發送信息，每個線程獲取號碼數量由“創建掛機短信羣組時，一個子羣組所包含最大的號碼數量”控制；
根據“發送限制方式”、“限制名單”、“掛機發送號段配置”配置，發送線程將數據取到內存，處理完成後將結果寫入t_rule_hangupsendsmlog表。
2、數據構造：
3、資源觀察：
運行時長(秒)、平均每秒入庫(條)、成功數
select (max(t.updatetime) - min(t.updatetime)) * 60 * 60 * 24 column1,
count(*) / ((max(t.updatetime) - min(t.updatetime)) * 60 * 60 * 24) column2,
count(*) column3
from t_push_groupmember t
where groupid in (select groupid
from t_push_groupinfo
where groupname = '創建的羣組名稱')
並行任務時，執行以下語句
select (max(t.updatetime) - min(t.updatetime)) * 60 * 60 * 24 column1,
count(*) /
((max(t.updatetime) - min(t.updatetime)) * 60 * 60 * 24) column2,
count(*) column3
from t_push_groupmember t
where groupid in (select groupid
from t_push_groupinfo
where (groupname = '創建的羣組名稱1' or groupname = '創建的羣組名稱2'))
需要保證創建的羣組名稱不同。
根據實際創建的羣組名稱，替換藍色部分。
僅支持多記錄一次性增加的情況。
CPU佔用(%)
sar -P ALL 2 0 > CPU.txt
"2"表示時間間隔爲2s，"0"表示收集總次數，如果爲0則表示無限次，如果>0則在執行完指定的次數後自動退出；後面的">"符號表示把數據輸出到CPU.txt文件，測試後完成後，我們對CPU.txt文件進行分析即可。
內存佔用(MB)
sar -r 2 0 > MEM.txt
"2"表示時間間隔爲2s，"0"表示收集總次數，如果爲0則表示無限次，如果>0則在執行完指定的次數後自動退出；後面的">"符號表示把數據輸出到MEM.txt文件，測試後完成後，我們對MEM.txt文件進行分析即可。
3.5 短信回覆(開戶類)
1、流程分析：。
2、數據構造：
3、資源觀察：
3.6 短信回覆(下載類)
1、流程分析：。
2、數據構造：
3、資源觀察：
3.7 數據同步(規則羣組)
1、流程分析：。
2、數據構造：
3、資源觀察：
3.8 數據同步(動態歌曲)
1、流程分析：。
2、數據構造：
3、資源觀察：