压力测试报告

压力测试报告

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

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