壓力測試報告

壓力測試報告

在beta階段尾聲時，咱們對網站進行了一次壓力測試。同時咱們也對alpha發佈以及去年的產品作了一樣的測試進行對比。測試代碼能夠參考咱們上一篇測試工具介紹的博客。

測試環境與項目

咱們使用了一臺vultr服務器進行測試，配置爲1c/1G RAM+1G swap/1Tbps/LA，與生產環境相同，測試時間爲凌晨2點左右，確保儘可能不影響正經常使用戶以及性能瓶頸不在測試服務器上。測試環境與生產環境相對獨立，是當時生產環境的快照，確保用戶資料的安全性。在測試時咱們臨時禁用了CSRF，CROS，IP訪問限制以及CDN。咱們作了如下測試，測試了去年的網站以及alpha（被攻擊修改後），beta階段的網站：

編號	內容	目的
1	使用siege，併發發起1000個請求，訪問首頁。	測試網站的併發處理能力
2	使用siege和本身的腳本，併發發起1000個請求，訪問獲取評分接口。	測試網站緩存及高資源佔用接口處理能力
3	使用本身的腳本，持續10秒，每秒發起200個請求，訪問搜索課程接口	測試長時間較大壓力的狀況（有緩存）
4	使用本身的腳本，發起1000個請求，向「數據庫技術基礎」課程評論評分	數據庫壓力測試
5	使用本身的腳本，發起2000個請求，隨機訪問搜索頁面，記錄執行時間，成功率	綜合測試數據庫，緩存，網站

本身的測試程序基本結構以下：

import requests
import threading
import time
class thread1(threading.Thread):
    count200=0
    count502=0
    count504=0
    count500=0
    countelse=0
    def __init__(self, threadID, name):
        threading.Thread.__init__(self)
        self.threadID = threadID
        self.name = name
    def run(self):
        time.sleep(15)

        a = requests.get(TEST_URL)
        code = a.status_code

        else:
            pass
        if int(code)==200:
            thread1.count200+=1
        elif int(code)==502:
            thread1.count502+=1
        elif int(code)==504:
            thread1.count504+=1
        elif int(code)==500:
            thread1.count500+=1
        else:
            print(code)
            thread1.countelse+=1

if __name__=="__main__":
    True
    threads=[]
    for i in range(2000):
        thread=thread1(i, "Thread-{}".format(i))
        threads.append(thread)
    a=time.time()
    for i in threads:
        i.start()
        time.sleep(0.005)
    time.sleep(50)
    print(thread1.count200,thread1.count502,thread1.count504,thread1.count500,thread1.countelse)

測試結果

測試1

階段	成功次數	成功率
去年	186	18.6%
alpha	1000	100%
beta	998	99.8%

咱們認爲有兩次請求未成功多是偏差，alpha與beta階段在主頁代碼與緩存邏輯上未作大量修改。總的來講，就去年的網頁有較大的提高，主要緣由是咱們將頁面渲染從服務器端調整到了客戶端。

測試2

階段	成功次數	成功率	HTTP502	HTTP504	HTTP500	else
去年	沒有這個接口	-	-	-	-	-
alpha	527	52.7%	466	0	5	2
beta	911	91.1%	89	0	0	0

能夠看到，咱們的beta階段比起alpha有了不小的提高，主要是由於咱們優化了緩存方式，創建了專用的緩存表。

測試三

階段	成功次數	成功率	HTTP502	HTTP504	HTTP500	else
去年	0	0%	362	961	677	0
alpha	1645	62.25%	108	121	126	0
beta	1750	87.5%	156	94	0	0

去年的程序絲毫沒有考慮緩存的狀況，所以在高計算資源需求接口發生併發時就直接炸了。後來通過手動測試，去年的接口併發大概在10左右。
beta相較於alpha主要是緩存方式略微優化，所以差異較小。

測試四

階段	成功次數	成功率	HTTP502	HTTP504	HTTP500	else
去年	沒法運行此接口	-	-	-	-	-
alpha	597	59.7%	403	0	0	0
beta	923	92.3%	77	0	0	0

去年的程序沒法成功調試出這個接口，所以未作測試。
事實上咱們beta階段與alpha階段評論接口未做什麼修改，然而成功率差距較大。咱們猜測緣由是上次被攻擊後數據庫中留有大量信息，儘管被邏輯上刪除了，可是物理上依然存在，所以拖慢了速度，相似上次數據庫評測中sqlite3在較大數據規模下的插入時間。

測試五

階段	成功次數	成功率	HTTP502	HTTP504	HTTP500	else
去年	0	0%	-	-	-	-
alpha	1023	51.15%	333	600	44	0
beta	1525	76.25%	143	115	0	217

與測試三的緣由相似，去年的程序此接口的併發極低。
相較於測試三，這個測試考慮了無緩存的狀況。咱們對於搜索全部課程是默認有緩存的，而隨機搜索的第一次是無緩存的，所以負載會大很多。這個接口仍然有不小的改進空間。

總結

總的來講，咱們的網站現階段在200併發下達到了90%左右的可用性。在實際應用中，咱們的網站不多會遇到這種強度的併發，咱們的小時活躍量在10左右。此外，在遇到惡意攻擊時咱們已經有了應對經驗，能快速解決問題。

所以咱們認爲咱們的網站在壓力測試下表現良好，符合預期目標。