压力测试与优化记录

为了检测我们部署的项目的性能，我们对我们的项目进行了压力测试。由于我们项目中最容易出现高并发的操作是抢票，我们主要对抢票操作进行了压力测试。

一、服务器配置

• 服务器：腾讯云 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" 的错误请求数之和与实际抢到的票数相等，因此并不会使数据库出现错误。
为了提升性能，最直接也最有效的方式是提升服务器性能和带宽，当然对数据库和逻辑的优化也很重要。我们对项目中数据库的配置与访问进行了一定的优化，以下是优化操作与优化后的测试结果。

五、优化操作及测试结果

1、去除外键约束

2、去除外键约束+去除索引

3、去除外键约束+去除索引+优化数据库访问