接口性能优化日记
背景功能冒烟演示的时间，发现一个接口的返回时间有时会实行5秒才返回，被测试提了一个题目。这个接口是我负责，所以需要我行止理。
过程
一开始，我不知道如何入手，于是我在一些可能会导致耗时的代码前后加上了log日志，打印耗时（比如http调用，mysql操纵）。
然后被pm说了，他说可以通过“听云”查察接口性能。
我去，另有这么牛逼的体系吗！
登录"听云"后，我找到了我谁人接口，可以看到io网络、code、sql、nosql的耗时，真的很牛逼。
回到正题，这个接口耗时5秒多，有5秒是耗费在了一个方法调用上（长途调用）。于是我就兴冲冲拍板，心想直接把这个调用改成异步不就得了！
我将这个长途调用方法改成了异步，然后提交代码。不久pm跟我说，你这样改，项目都被你改崩了。
我想：我去？异步还能崩？
pm：”这个长途调用，占了5秒，你整个接口耗时才5秒多，你即使把整个长途调用异步，你最多节省一百毫秒，这能办理题目吗？“
我想：”有道理啊，我这个蠢蛋！“
pm：”这个调用涉及到zookeeper单机，且服务器性能都很差，所以调用会很慢，你可以把它改成feign调用就好了！“
我想：”牛逼！“
总结
接口性能优化，我们本能会想到
[*]现状：压测目前接口性能吞吐（知道性能到底多差）
[*]定位：哪个步骤导致性能低
[*]办理：针对题目举行办理
[*]回归：重新压测，确认是否已经改好
其中办理的手段就是异步、缓存。
但我这次的题目就是异步、缓存都无法办理的，因为这个题目的耗时，占用整个接口耗时的99%。
有时间我们要多想！
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]