为了检测我们部署的项目的性能，我们对我们的项目进行了压力测试。由于我们项目中最容易出现高并发的操作是抢票，我们主要对抢票操作进行了压力测试。
一、服务器配置
- 服务器：腾讯云 CVM 标准型S3
- 操作系统：Ubuntu Server 16.04.1 LTS 64位
- CPU：Intel(R) Xeon(R) Gold 61xx CPU 2核
- 内存：4 GB
- 公网带宽： 5 Mbps
二、项目配置
- Django版本：1.9.5
- uWSGI版本：2.0.17.1
- NGINX版本：1.10.3
- 数据库：MySQL 5.7.23
- Django项目配置：
Debug：False
IGNORE_WECHAT_SIGNATURE: True (为了进行性能测试)
三、压力测试设置
我们使用了JMeter进行压力测试，JMeter的使用请参考https://www.jianshu.com/p/5d50627cd692 (作者：吴海旭) 。
我们设定了6种票数与访问数的组合，进行了6组测试，我们设定的请求启动时间为1ms，即在1ms内启动所有请求线程，每个线程发送一个POST请求。一组测试过后，我们记录了请求失败的次数，即JMeter报错的次数，包括 failed to respond, connection reset, Gateway Time-out等多种错误信息，并计算了请求失败率(请求失败次数/访问数)。我们检查了数据库中活动余票数和票的张数，来验证我们代码逻辑的正确性，即不会出现票的张数与活动余票数不一致的问题。我们还记录了平均响应时间，作为我们性能优化的指标。
四、原始版本（未经优化）测试结果
| 票数 | 访问数 | 请求失败率 | 余票 | 数据库正确率 | 平均响应时间/ms |
|---|---|---|---|---|---|
| 100 | 1000 | 0.00% | 0 | 100% | 2599.25 |
| 100 | 10000 | 6.20% | 0 | 100% | 1712.71 |
| 1000 | 1000 | 15.90% | 159 | 100% | 1170.53 |
| 1000 | 10000 | 47.01% | 0 | 100% | 1572.01 |
| 10000 | 1000 | 18.40% | 9181 | 100% | 1184.87 |
| 10000 | 10000 | 74.26% | 6941 | 100% | 1643.2 |
测试结果可见，当票数与访问数增加时，请求失败率也会增加。由于 JMeter 计算平均响应时间包含了错误的响应，而错误响应时间极短，因此使得平均响应时间受到了错误率的影响。我们检查了数据库，数据库Activity中的活动余票数与Ticket中的票数之和为总票数，因此我们的数据正确性得到了验证。我们发现成功请求数有时会小于实际抢到的票数，经检查错误请求的错误原因发现，失败请求中有部分请求错误信息为 "504/Gateway Time-out"，说明服务器响应超时，但实际上用户已经抢到了票，只是由于服务器响应速度慢导致的。而成功请求数与错误信息为 "504/Gateway Time-out" 的错误请求数之和与实际抢到的票数相等，因此并不会使数据库出现错误。
为了提升性能，最直接也最有效的方式是提升服务器性能和带宽，当然对数据库和逻辑的优化也很重要。我们对项目中数据库的配置与访问进行了一定的优化，以下是优化操作与优化后的测试结果。
