接口性能测试实战小结(附点评)

背景

有一个接口http的接口,GetPaymentURL,传递参数很简单,就是一个sessionID(类似于订单号),这个接口本身并没有什么东西,但是他调用了另外一个模块钱包的接口,钱包最终会返回一个paymenturl等信息给到GetPayment这个接口。

一句话,GetPyamentURL只时负责传递参数给到钱包的接口,主要业务逻辑都是在钱包里面,最终由钱包把结果返回给GetPaymentURL ,拿到结果后再做简单的处理,把结果返回出来。

小强点评:明白一个接口的逻辑是非常重要的,实际中我发现很多人只关注技术,却不关注业务逻辑,导致很多一步可以完成的事情偏偏走了N步,得不偿失啊!

问题 

当时遇到一个情况,调用getpaymenturl接口有时非常慢(只是1个用户进行调用,100次内有27次是20秒以上,最长的都达到30秒以上。我这只是单个用户进行请求啊,怎么能这么慢),但是直接调用钱包的接口非常快。而且都是在同一网络下用一个用户分别进行测试100次,都是在我们公司的内网发出请求的请求。

小强点评:我就想说棒棒哒,哈哈

分析 

首先,因为直接调用钱包接口,响应正常。所以我觉得问题应该是在getpaymenturl这里。

我利用LR,把getpaymenturl的结果分析了一下,发现buffer time非常长,进一步分解,得到server time很慢,net time是正常的。所以我怀疑是不是GetPaymentURL接口本身的server端问题,导致慢。但又觉得说不过去啊,这个接口只是做了简单的传递,怎么会这么慢,不太可能?所以我觉得还是保留一下网络的原因。

接口性能测试实战小结(附点评)

然后我又想,不对啊,为什么直接调用钱包接口,都正常,说明网络是正常的。后来与同事确认后,后来发现直接调用钱包接口走的是公网(开发给我的测试地址是公网的),而getpaymenturl应该走的是专线。虽然最终都是到达同一台服务器进行处理,但是他们走的网络节点是不一样的。所以现在我更加肯定,网络+VPOS都有可能有问题。

小强点评:分析逻辑严谨,能放能收。抓住网络路径的不同找突破口

这里还有一个小故事。VPOS一开始其实用的是公网地址,然后我们这边的一个同事,配置了一个什么代理,就是无论VPOS用什么公网地址,都会被这个代理,转一下,最终跳到一个固定的地址,然后再从这个地址转出去,再到钱包。

这样搞,显然不行,一是对于这种涉及到钱的交易,肯定是走专线地址的。 而是即使走公网,为什么还绕了这么大一圈子,通过配的什么代理,兜一圈再出去。。。

于是立马,让同事修改成为指向钱包的专线地址,重新测试了一下,结果一切正常。

虽然结果有点大跌眼镜,既不是网络原因,也不是VPOS服务端的原因,而是莫名其妙的被兜了个大圈子,导致响应时间较慢。

这是最终用单个用户请求了200次的结果:

接口性能测试实战小结(附点评)

小强点评:为什么性能测试好玩?就是你会发现有时候你玩他,有时候他玩你啊,就和大家为啥都爱看悬疑推理破案片一个道理,所以耐心、坚持、逻辑思维真心很重要。不过这里我建议用的工具要保证一致性,毕竟每个工具的统计原理不一样,如果换着用会对数据的比较造成一定的干扰。这里学员用了jmeter,而上面用的是loadrunner。

总结

1. 遇到这种接口很慢的情况,无非就是网络+Server端的原因。

2. 对于这种接口调接口的情况(某个接口本身封装了另外一个接口),可以进一步拆分。比如直接调用钱包的接口,看看他是否正常,如果他本身就有问题,那肯定是要首先分析钱包的接口。 如果钱包接口本身没有问题,那就要分析是不是getpaymenturl本身接口的问题

3. 遇到问题,要与相关人员进行确认。

小强点评:这里的总结看起来短短几字却透出了我一直传达的一个信息,那就是分析问题要学会分层拆分!只有把大的拆成小的我们才能慢慢找到突破口,很多人觉得分析难不会分析,本质就两点,一点是基础不够扎实,二点就是不会拆分,不知道该怎么一步步拆解。


猜你喜欢

转载自blog.51cto.com/14478010/2427773
0条评论
添加一条新回复
  
今日推荐