背景

目前在某厂又开始了php，哎，逃不掉的php。又碰上了优化季度，所以被分了2个接口优化下，要求达到3个9就行。目前是2个九，嘿嘿，要求已经很低了是吧？但是php这个东西还是比较难搞的。

基础实施比较差的，也没有服务化，像有的服务化做的好的，可以直接分布式链路追踪看出耗时在哪里。

同时希望最小改动原则，成本尽可能的低，效果尽量早点体现出来。

开始

1.先弄清3个9是根据啥统计的

对的，我们要达成目标，就先要知道目标是怎么统计的。后面我去问了下，发现是统计nginx的日志，非200的/200的，就是指标了。

再结合监控看，发现目前非200的码499比较多，这个499不是标准的http 状态码，而是nginx自定义的。意思是说前端主动断开了链接，可以理解为服务端处理太慢，前端等不及就断开了链接。

也就是说，这个php的app确实是慢。平均耗时达到了700多ms。捞了一些499的日志，几秒的请求

多的是。这里也可以统计下分为，90分为的请求占比多少。等等。

总结：这里我们了解到了，服务端的处理慢，导致了比较多的超时，从而nginx日志打印499，从而我们的指标是差的。下一步就是查一下哪些地方比较耗时。

ps：在查看监控时发现了一个有用的地方，某天的上线，导致了一个接口平响增加了200ms。

具体见4

2.先梳理接口的业务

优化接口，了解业务是不可缺少的，否则就是纸上谈兵。所以首先我将接口里有IO调用的都用流程图画了出来。不画不知道，一画吓一跳，各种重复调用，套娃，看起来真的晕，有的重复调用居然达到了5次，明明都是相同的请求，相同的响应（从这个地方我们就能获得启发，虽然写业务代码，但是要明白业务呀，明明上个函数都返回你需要的数据了，这个函数又查一次）。

从这个过程我们简单了解了业务，也知道了一些优化点：复用数据，减少重复请求。

ps：其实有一些工具是可以借用的，比如go里面的pprof来帮助我们分析。但是php这个不太熟，后面也了解到是有的，然后查看了一下这个接口的调用链接和耗时，结果烂的一滩，看不出来啥。因为套娃太严重了。根本不知道从哪看，从哪下手。所以这个地方，我认为想单凭工具来分析的前提，是你的代码足够的清晰，而且有的地方确实有耗时问题。目前我这个代码，并没有说某次io耗时，而是套娃严重，一个函数里面有十多次IO调用。在不影响业务的情况下，难顶。那么有人会说了，那你改一下不就行了吗？。。。可是，改动会特别多，需要特别熟悉业务的人才好把握，而且有的函数特别深。你可能需要把结果一直传到底，这个成本是很高的，可以理解为重构了。

3.找线上耗时的请求来请求测试环境看看是否能复现。

于是我去捞了导致499的用户请求日志，把一些请求放到测试环境去测试，也感觉不出来啥，缺少并发的环境，所以没啥。

4.并发

第一条中说了发现了某次上线导致了平响增加了200ms，去上线该需求的同学了解到了，这个算是独立的，和这个接口其它的没有上下文关系（感觉弄个独立的接口比较好？）。那么比较好办的就是把这部分放到线程里面，并发起来。可是这是php啊，怎么并发呢？好在厂内有对应的方案（具体实现我也不懂，php也懒得去深入，能用就行了）。

好的，加完后，测试完毕后开始上线，下面就是激动人心的时刻了。最终是平响下降了130ms左右吧。效果还行，但是目前没达成，99.68，还是没到3个9。

别灰心，有并发的手段了，后面的就都好说了，胜利就在眼前。

5.代码抽丝剥茧

结合第二部给出的图，再结合代码，再结合线上io调用耗时日志，也发现了一些优化点，比如redis请求有的地方没做批量。有的地方缓存粒度太细，比如说可以设置个整个函数的粗粒度的缓存。

询问熟悉业务的开发或者pm，查看哪些地方可以是不是有不用的逻辑，字段啊，看看是否可以去掉。

总结：从这次我们可以得出一些优化方法： 1.批量 2.缓存设置 3.去掉无用的业务逻辑

这次上线后，达到了99.87,快了。

6.绝杀

目标还是没有达到。现在结合前面的信息，我们还能做出一些优化。那就是结合3，4。那么现在有请求了，也有并发手段了。那么那些地方该设置并发呢？

这里有几个原则。

1.原则上最上层能做并发的，就不去底层，在最上层做，只会影响本接口，如果在最底层做，修改底层方法是最严重的。

2.找到耗时严重的上层函数，结合上下文依赖做并发

这里我用到了很笨的方法，在上层的每个函数打印了耗时，即在函数调用前打印时间，结束后打印时间。虽然笨但是很有用，这样就明白了哪些函数是耗时严重的，才好控制如何做并发。

比如。A （40）-> B（70）-> C（100）三个函数。 C是不依赖A，B的结果的。同时C的耗时是比较高的，那么我们完全可以这样 C（开线程） A->B??C(等待结束)。那么这样的效果是非常可观的。

这次上线后，目标就达成了，已经达到了99.97，喜大普奔。

ps：有一些数据是要提前知道了，比如评估本次优化后预期是降多少ms。所以我用了postman的一个接口测试，优化前用一个请求跑了500次，得出了平均耗时。优化后又用同一个请求跑了500次，得出平均耗时。那么差值就是我们的预期，当然线下和线上的机器，db等是不一样的。所以这个值可能是会有放大或者缩小的。不过有正向的收益就是可以上线的。