前端性能优化重要吗(代码性能优化)

　　　　每当失败发生时，背后都没有并发测试。当该测试验证缺失时，您的微信、电话和电子邮件将收到一大堆慰问。关于，我会写下一些经验，这是方便更多的人。可以得到一些方向性的思考，　　

　　

　　　　　　

　　

　　　　　　

　　

　　　　　　

　　

　　　　　　

　　

　　　　很多时候当服务出现在这一页时，他会觉得服务死了，那个服务卡顿，毫无疑问这是真的死了，但是我们在死的时候需要有一系列的措施。　　

　　

　　　　是什么导致了这次绞刑？　　

　　

　　　　1.504后台服务超时，进程挂起？满了吗？网络断开？　　

　　

　　　　2.502的后端没有提供服务？连个人都找不到？　　

　　

　　　　吃完饭，我们还有调查的方向。从哪个链接开始，做一些小测试，比如直接去监控看看进程是否在那里，CPU，内存，网络上是否有流量　　

　　

　　　　解决方法　　

　　

　　　　添加机器？升级配置？　　

　　

　　　　等一下~，我们看到的这些东西好像都是现象。我们不去想为什么，整体流程是怎样的，为什么这个时候会发生一些事情。我们需要全局思考这个问题，搞清楚整件事的原因，知道原因就知道如何有效解决问题。　　

　　

　　　　其实慢接口很正常。要搞清楚为什么慢是为了正视这个问题。一般而言，slow侧重于外部链接、数据库等的循环查询。　　

　　

　　　　解决方法　　

　　

　　　　缓存？　　

　　

　　　　这时候就不是在外面加缓存的问题了。缓存仍然被坑。它没有考虑渗透率、破碎率和命中率。此外，对于商品价格，仍有一套后续措施来确保订单无法下达。处理(订单价格检查)　　

　　

　　　　此时，我们首先通过代码片段记录运行时间　　

　　

　　　　显然我自己也访问过界面，没有问题的响应时间在几百毫秒以内。为什么机器推广时会出现停机的问题？　　

　　

　　　　这也是正常的，因为当你拜访自己的时候，你只有自己，却是并发的。如果接口卡有多个并发请求，所有进程线程都会占用处理请求。因为处理速度太慢，后续请求无法响应。前端没有做过一些限流处理(前端不只是CSS js)。这时候你只能等几天才能看到车水马龙的时候。　　

　　

　　　　解决方法　　

　　

　　　　上线前测试，了解你的限制，看看如何使用缓存，限流，灵活性，或防止其他人的流量攻击处理　　

　　

　　　　外部途径有　　

　　

　　　　高并发意味着　　

>　　

　　　　应用拆分，缓存，队列，扩容、限流，熔断、降级、数据拆分（垂直，水平）

　　

　　　　以下是自己思考且实践过

　　

　　　　1、整个连路的监控与报警，除了常规的机器报错外，我们还需要针对业务主流程进行数据报警，检查时候出现业务问题，如流量渠道统计，漏斗统计，转化率统计，接口响应速度等

　　

　　　　2、减少调用链，避免循环读库，适当使用并发查询，批量查询，后续结果在运算

　　

　　　　3、缓存，把运算好的结果保存好持久化数据库，并且放入缓存，这种方法避免缓存失效大量并发运算产生问题，但这种需要先把运算好的结果放到数据库的话，联动更新需要跟上，不然客户会找上门

　　

　　　　4、线程池，共享数据，提高并发，这个时候就需要加机了，但要注意，如果下游如数据库只有1000的连接数，你的线程2000个，这个时候你需要祈祷下，有一般的处理连接不上数据，就不要傻bb地说，什么mongodb垃圾，mysql垃圾了

　　

　　　　5、长连接，使得使用，减少网络重连

　　

　　　　6、上下游超时时间递减，如果下游服务超时时间超长，你都断开连接了，人家还在运算，就算运算完了，你也不会收到结果，因此超时时间，不要设置太长，3s 是一般业务的极点，避免进程线程卡主等待这些超长的超时时间

　　

　　　　7、上线前压测，知道自己系统极限与优化点

　　

　　　　这个就不用说太多了，ab 并发测试是好基本，会提前暴露问题，让你重新会思考上面的优化点，也便于你跟推广伙伴沟通

　　

　　　　8、熔断，拆分，限流且设置防刷机制（业务规则或高防），避免恶意流量

　　

　　　　被抓数据这个时候你需要限流与防刷

　　

　　　　如果某个推广流量真的特别大，大部分流量查看页面都是随便看看，特别专题页，这个时候就适当做缓存设置页面静态化缓存等

　　

　　　　总结起来

　　

　　　　1、多压测，知道自己的水平

　　

　　　　2、上下游连接数需要递增，超时时间需要递减

　　

　　　　3、一定要建立监控，报警，你要提前发现问题，不是让人家提点你

　　

　　　　上线前的接口响应时间

　　

　　　　" data-caption="" data-size="normal" data-rawwidth="182" data-rawheight="198" class="content_image lazy" width="182" data-actualsrc="https://pic2.zhimg.com/v2-0ef9ae3395fac48ac4f5f367a265d42d_b.png"/>

　　

　　　　推广中的响应时间

　　

　　　　" data-caption="" data-size="normal" data-rawwidth="164" data-rawheight="302" class="content_image lazy" width="164" data-actualsrc="https://pic2.zhimg.com/v2-6a99964bbfd0f09fa87ed8b104e97495_b.png"/>

　　

　　　　并发高的机器情况

　　

　　　　突破极限线，所有请求都忽略

　　

　　　　

　　

　　　　一看推广跟平时没有变化啊，为什么上线一个新功能就产品问题

　　

　　　　一看数据监控

　　

　　　　发现调用连过长，而且有调用链时间达8s以上到就算是弹性扩容，这个时候都是徒劳，直到极限挂机为止

　　

　　　　

　　

　　　　每个模块调用链都过长又多，导致一个触发某个模块弹性，某个模块又触发某个弹性，导致资源耗尽

　　

　　　　

　　

　　　　现在问题清楚了

　　

　　　　1、调用链过长

　　

　　　　2、接口运算速度过慢，放大调用链每个环节的卡顿

　　

　　　　因为我们业务建立于函数计算，当时设想是每个业务功能单一功能都变成一个函数进行处理，通过http调用方式进行调用处理

　　

　　　　这种处理不好其实是一种灾难，因此对于调用方调用某模块的功能进行运算的话，会就行异步运算后持久化把数据放到一个宽表进行保存，减少用户读取时候产生大量运算

　　

　　　　就如多个表查询，把他们的结果结合起来放到某个地方，是放到内存，还是nosql，mysql，这个就看你业务

　　

　　　　你可以理解成缓存的write back

　　

　　　　

　　

　　　　最终处理措施

　　

　　　　建立宽表，如某记录更新，异步进行

　　

　　　　结果

　　

　　　　ab测试结果为

　　

　　　　100 并发，响应时间中位数464ms - 比较优

　　

　　　　200 并发，响应时间中位数1300ms， 因为列表数据要根据坐标进行数据筛选，这个优化需要后续再处理，目标要达200并发，300ms 左右，方向为实例缓存减少外部连接，也就是缓存预热

　　

　　　　函数计算弹性为160由于php一个实例只能处理1个并发因此受限