界面性能问题，对于从事后端开发的同学来说，这是一个绕不开的话题。要优化一个接口的性能，需要从很多方面入手。
事实上，我写了一篇关于界面性能优化的文章《聊聊接口性能优化的11个小技巧》。发表后，我在网络上受到好评。感兴趣的年轻人可以仔细看看。
(相关资料图)
上周，我优化了网上部署评分查询界面，将界面性能从一开始优化到现在以内。
总的来说，三招都做完了。
到底经历了什么？
我们每天早上上班前，都会收到包含等信息的在线慢查询界面摘要邮件。
我看到其中一个批量分数查询界面需要最大时间，平均时间。
从这个接口的调用信息来看，绝大多数情况下，接口响应比较快，大多数情况下，500毫秒左右就可以返回，但也很少请求超过20s。(大卫亚设，Northern Exposure)。
这个现象很奇怪。
那和数据有关吗？
例如，检查一个组织的数据非常快。但是，如果要确定平台，需要查看的数据量非常大，界面响应可能会非常慢。
但这不是原因。
不久，一位同事给了答案。
他们在账单目录页面上大量请求这个接口，但他传递的数据量很大。
发生什么事了？
当初说的要求是这个界面是对分页的列表页面调用，每页大小为10203050100，用户可以选择。
也就是说，调用批处理评估查询界面时，一次最多可以查询100条记录。
但是实际情况是，结算清单页面也包含很多订单。基本上所有结算书都有多个订单。调用批评估查询界面时，必须合并结算书和订单数据。
因此，调用批量评估查询界面时，一次传入的参数非常多，参与list可能包含数百或数千个数据。
一次传递数百个或数千个id，批量查询数据就可以了，可以使用主键索引，查询效率不会太差。
但是，其大规模分数查询界面逻辑并不简单。
伪代码如下：
事实上，在真实场景中，代码比这复杂得多，为了在这里展示，简化了。(威廉莎士比亚，代码，代码，代码，代码，代码，代码，代码，代码，代码)。
最重要的是两点。
从接口远程调用了另一个接口
必须在For循环中查询数据
其中一次，即从接口远程调用另一个接口。此代码是必需的。
因为，如果在中复制组织代码字段，则在某一天修改组织代码时，必须通过同时修改评估表中的组织代码的机制通知您。否则，可能会出现数据不一致的问题。
显然，如果要这样调整，业务程序需要改变，代码更改要大一些。
因此，最好先从接口远程调用。
这样看来，可以优化的地方只有：for循环可以查询数据。
因为必须在For循环中，所以每个记录必须根据不同的阈值查询所需的数据。
因为业务系统调用该接口时没有传递，所以在门槛上不容易使用，可以大量查询数据。。
这样会使SQL语句变得非常长，并降低性能。
其实还有另一种写法。
但是这种SQL一次查询的数据量太多，性能也不好。
不能改为批量查询，只能优化单个查询SQL的执行效率。
先开始吧。因为改造成本最低。
第一个优化是。
因为我决定性地添加了：
统一索引由和四个字段组成。
经过这次优化，效果立竿见影。
大规模评价查询界面需要最长的时间，从初期开始左右缩短。
因为必须在For循环中，所以每个记录必须根据不同的阈值查询所需的数据。
只从一个线程查询数据显然太慢了。
那么为什么不能改为多线程调用呢？
第二次优化，查询数据库从更改为。
但是，该接口将返回所有查询的数据，因此必须获得查询结果。
要使用多线程调用并获取返回值，建议在此场景中使用java8。
代码调整大象：
的本质是创造执行力。必须使用，以避免生成太多线程。
建议使用类。自定义线程池。
具体代码如下：
也可以使用类创建线程池。
通过此次优化，界面性能也提高了5倍。
左右缩短。
但是整体效果还不理想。
通过前面两个优化，批量查询评估界面性能有所提高，但花费了大量时间。
这个问题的根源是：
那么，为什么不限制我们一次查询的记录数呢？
第三个优化限制了一次性查询中的记录数。事实上，以前也有限制，但最多有2000个记录，目前效果不好。
限制界面一次只能检查一条记录，超过个时会报告错误提示。
如果直接限制此接口，业务系统可能会出现异常。
为了防止这种情况发生，必须与业务系统团队讨论优化方案。
主要有以下两种方案。
在“结算列表”页上，默认情况下，每个结算仅显示一个订单一个附加页面视图。
在这种情况下，如果按每页最多100条记录计算，结算书和订单一次最多只能查看200条记录。
这需要业务系统的前端，后端接口需要调整支持。
但是目前的情况是前端没有多余的开发资源。
由于人手不足，这个方案目前只能暂时搁置。
业务系统后端以前调用评估查询界面，但现在改为调用。
例如，如果以前查询了500条记录，则业务系统只调用一次查询界面。
现在换成业务系统，一次只确认100条记录，分成5个调用，共查询500条记录。
这样不就慢了吗？
答：如果评估查询接口的5个调用是for循环中的单线程顺序，则整个时间可能会变慢。
但是，业务系统也可以更改为调用。只需最后总结结果。
此时，评估查询接口的服务器多线程调用可能会出现与其他业务系统中的多线程调用不相同的问题。
在大量评价查询界面的服务器中，为什么不做大一点呢？
显然你忽略了一件事：在线应用程序一般不会作为单点分发。大多数情况下，为了避免服务器中断和单点故障，默认情况下至少部署两个节点。这样，即使一个节点丢失，也可以正常访问整个应用程序。
当然，如果断开一个节点，也会出现其他节点访问的流量太大，承受不了压力或中断的情况。(大卫亚设，Northern Exposure，访问，访问，访问，访问，访问)
这意味着，通过业务系统的多线程调用接口访问接口的流量负载可以平衡到其他节点。
他们还使用8个线程对数据进行批处理，每批记录100条记录，最后总结结果。
通过这次优化，界面性能再次提高。
从左右减少到细小。
提醒大家，无论是从批处理查询评估界面查询数据库，还是从业务系统调用批处理查询评估界面，使用多线程调用都只是一个临时方案，并不完美。。
这样做的原因主要是为了尽快解决问题。因为这种方案的变化最小。
要从根本上解决问题，可能需要重新设计此功能修改表结构和修改业务流程。但是由于涉及多条业务线和多个业务系统，所以只能在一段时间内慢慢来。
如果想得到更多关于界面优化的提示，可以看我的另一篇文章《聊聊接口性能优化的11个小技巧》。
