压力测试报告

压力测试报告

在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左右。此外，在遇到恶意攻击时咱们已经有了应对经验，能快速解决问题。

所以咱们认为咱们的网站在压力测试下表现良好，符合预期目标。