性能测试中响应时间长，吞吐量低的问题接口压测过程

我在做本次国庆抽奖项目时遇到了一个很严重的问题，就是响应时间超长，导致吞吐量和服务器CPU上不去。应该如何解决这类问题呢？

首先得清楚响应时间超长是哪个节点的时间长，是连接端响应时间长还是服务器处理端的响应时间长。

对接口进行瞬时并发测试，添加集合点定时器。这种场景下该问题通过添加表格结果就能清楚的知道。

从上图看到，connect time（连接时间）非常接近latency（响应时间），由此可知耗时花费在连接时间上。

连接时间超长的阻塞大致有：网络阻塞、tcp传输超时、tomcat和数据库连接池/最大连接数不够用（资源抢占）、线程有死锁、程序中有慢SQL。

在外网使用长连接的方式对接口进行负载测试，tps还是上不去，服务器CPU利用率也很低，暂时考虑是网络阻塞。

在内网使用长连接的方式对接口进行负载测试，TPS是外网TPS的3倍，服务器CPU利用率从百分十几上升到百分七十左右，确认外网环境存在网络阻塞。

持续运行2小时后jvm开始出现FGC现象，但是性能指标还未达到准出标准。由于测试环境服务器配置为2C2核，改为在生产环境进行压测，生产环境是多台服务器搭建的负载均衡，配置足够高。

在生产环境对其中一个接口进行负载测试，得出一下对比数据，进一步验证外网存在严重的网络阻塞问题，测试环境资源不足。

环境	网络	吞吐量	响应时间	服务器CPU	其他资源
测试环境	外网	130/sec	1.5s	12.5	正常
	内网	1700/sec	0.9s	70.0%	正常
生产环境	外网	150/sec	0.59s	不到5%	正常
	内网	6646/sec	0.18s	不到15%	正常

本接口在生产环境的性能指标是达标的，该接口完成测试。

  其中一个接口在生产环境内网压测，吞吐量只有850/sec，达不到性能指标，表格检测结果中大约每隔10-25个请求就产生一个响应时间超过1秒钟的请求。

初步断定吞吐量上不去的原因就在此。通过查找日志发现关联程序中有一个SQL比较慢，对该sql添加索引。tps运行监控直线飙升至1700/sec。

如下所示：

经过压测得出该接口最佳性能可达到2149/sec，响应时间0.15，该接口达到性能准出标准。

另一个接口，发出的请求无法到达服务器，全部卡在客户端与服务器之间。如下所示：

开发重塑接口逻辑，给SQL添加索引，优化数据库里的数据，然后进行复测。得出如下结果：

接口最优性能：700线程，吞吐量7055/sec，响应时间168ms，该接口达到性能准出标准。

最终得到如下数据：