多个人同时调用接口_复杂业务接口优化实践

背景

用户中心有2个核心接口，index和queryMyInfo。

index接口的QPS是几百量级，queryMyInfo在几千量级，它们响应时间大约一百毫秒，线上功能满足业务要求。但在一次全链路压测过程中，发现流量2-3倍时，接口响应时间变长。当流量超过3倍时，响应时间到了秒级别，服务吞吐量上不去，而且服务器CPU和内存资源只使用了一半。

如果业务量翻倍，或者碰到大促场景，系统肯定有响应问题。为了用户体验和解决接口性能问题，开始着手优化工作。 

服务调用关系

首先说明一下接口的业务逻辑。index是APP中“我的”页面，查询各种信息组装成结果返回给用户。queryMyInfo是获取用户相关信息。 

index：提供用户信息、收藏、足迹、订单统计、C2C卖家和资源位等聚合信息，在APP中“我的”页面展示。queryMyInfo：提供用户信息，玩家信息和店铺ID，在APP中“个人资料”页展示和其他场景调用。 

index接口的调用关系如下图所示，依赖多个外部服务，组装多种业务信息，作为数据聚合提供接口服务。 

性能优化基本概念

性能指标

在具体优化之前，先介绍性能衡量的标准有哪些。
1. 响应时间 即Response Time，简称RT，从客户端发起请求到获得服务端响应之间的时间跨度。
2. 并发数 指客户端同时访问服务端的连接数，在不同的并发压力下会有不同的RT指标。
3. 吞吐量 一般用TPS或QPS等来衡量. 

TPS：Transactions Per Second指服务器每秒能够响应的事务次数。事务指客户端向服务器发送请求然后服务器做出反应的整个过程。
QPS：Queries Per Second指服务器每秒能够响应的查询次数。 

压测数据采集、分析

有了标准，我们怎样才能采集这些数据呢？
要想知道接口性能情况，通过模拟流量做性能压测。做压测前要确定压测的并发数，以及准备被压测接口的模拟请求参数和测试数据。在并发请求访问下，观察机器的网络、CPU、内存和磁盘IO等硬件的负载情况。通过不同的并发量，收集接口的RT情况和机器负载情况。 

压测提示： 

1. 服务器的网络带宽要高于压测数据包的流量带宽，如果网络层堵塞，会造成压测结果的不准确。

2. 评估CPU和内存的增长情况，平均使用率一般不超过服务器配置的80%。

3. 有文件操作的压测，还要注意磁盘IO的情况。

优化

压测情况分析

下表是在全链路压测情况下，queryMyInfo和index接口的性能指标，接下来解读数据。

压测次数	压测模拟请求	处理QPS	RT(ms)	CPU(4 core)
1	2倍基准	1700/370	379/132	23%