压测结论

本次压测环境所选的mysql未达性能瓶颈。

本轮压测环节redis未达到性能瓶颈。

压测过程中，ECS服务器CPU处于400%（4核）的满载状态。根据线程查看后，没有阻塞线程，平均CPU使用率为3%左右，为nio普通线程。

平均每个节点会大约增加230-240的吞吐。

API平均响应时间在2秒以内。

响应最慢的请求为提交订单，涉及mysql事务、缓存、数据查询、数据插入等较多工作。

5000并发时，尝试增加节点提高服务器响应速度，结果平均响应时间从2111.63提高到1758.86，效果显著，同时吞吐提升440。

订单极限压测中，除了ECS服务器，其他节点，中间件均为达性能瓶颈，5分钟入库400000订单。

错误问题描述

压测过程中，超过5000并发之后错误率提升到了0.10%，是由于并发注册后，注册接口返回异常导致无法注册、无法登陆、无法加入购物车、无法下单等操作，所以导致错误率到了0.1%，但是实际使用中应该是只有1/5的错误率，也就是实际错误率应该是0.02%。

redis在压测过程中出现过redis内存OOM的问题，是由于消费者不能及时的消费订单等缓存信息，短期内缓存均没有过期等问题导致，建议在生产环境时注意缓存内存问题。

前期压测过程中瓶颈均在数据库，由于事务与索引问题导致，自行压测或者生产环境时要慎用事务，以及应该对业务涉及的数据库索引进行优化。

建议实际生产环境运行时，最高并发量每增加500，增加一个节点，来保证用户的体验。

生产环境建议着重注意服务器数据库性能，尽可能在限度内提升数据库的性能。