压力测试报告
压力测试报告
在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左右。此外，在遇到恶意攻击时我们已经有了应对经验，能快速解决问题。
因此我们认为我们的网站在压力测试下表现良好，符合预期目标。
