.NET-记一次架构优化实战与方案-前端优化

目录

1. .NET-记一次架构优化实战与方案-梳理篇

2. .NET-记一次架构优化实战与方案-前端优化

3. .NET-记一次架构优化实战与方案-底层服务优化

前言

　　上一篇《.NET-记一次架构优化实战与方案-梳理篇》整理了基本的业务知识，同时也罗列了存在的问题，本篇主要是针对任务列表的页面进行性能优化。

　　该篇主要涉及的是代码实现上的优化，实现上的问题是战术债务，也就是咱们日常出现的各类BUG，这种问题一出直接影响业务运营与系统运做。

　　你永远想象不到同一条SQL相差个3.5秒钟，遍历两次就致使了 3.5秒*2次 = 7秒的耗时。具体请看下文。

二八原则

　　有接触过性能问题的朋友应该都了解过，通常性能瓶颈都是在某行代码或者某个方法，而不是整一个代码实现流程。

　　例如：遍历计算、没使用到索引的SQL语句、多余重复的接口请求等等。

　　以二八原则的思想来考虑，80%性能耗时由20%的代码引发，所以咱们处理原则就是具体定位，具体问题，针对解决。

现象描述

　　任务列表页面问题主要体现于加载任务列表过慢的性能低效问题，就如上一篇所说的加载事件须要11秒！这种对于用户来讲是不能忍受的，特别是以现状JOB触发的方式时效如此低，用户多看两次，估计就会有放弃该产品的冲动。

　　所以咱们须要遵照3秒钟原则。

3秒钟原则

　　现代人的生活节奏都很快，网页间的切换速度也愈来愈快。所谓“3秒钟原则”，就是要在极短的时间内展现重要信息，给用户留下深入的第一印象。固然，这里的3秒只是一个象征意义上的快速浏览表述，在实际浏览网页的时候，并不是真的严格遵照3秒。

　　所以，在设计互联网产品的页面时，用户等待时间越少，用户体验越好

优化实施

　　任务列表页面为以信息展现的读操做为主，所以对于 I/O 密集型程序，问题主要体现于两点：

1. 慢查询语句
2. 屡次创建查询

屡次创建查询

　　该问题主要从代码实现方式上解决，场景又分为两种状况：

信息重复查询

　　描述：函数 A 查询了一次 Users 信息，其函数 A 的子函数 B 又进行了一次查询了一次Users 信息。

　　解决方案：去除子函数 B 的重复查询，并提供参数由函数 A 传入

遍历查询

　　描述：item.foreach(item=> _userIdRespository.Get(a=>userId == item.userId) )

　　解决方案：先批量查询，而后在内存过滤。
　　var userIds = item.Select(a=>a.UserId);
　　var users = _userIdRespository.ToList(a=>userIds .Contains(a.userId));
　　Item.foreach(item=>{
　　Var user = users .where(a=>a.userId == item.userId)
　　})

以上并非什么特别牛逼的技术，可是每每是某些地方性能瓶颈点，而致使这样的缘由也只有一点，贪方便。上遍历查询的例子看出，两种写法的代码量的确差了几行，可是在实际使用场景中性能会差几倍，并且随着业务的增加其差距愈加的明显。

慢查询语句

　　对可能出现慢查询的语句的进行日志埋点记录耗时（特别是手写 SQL 与复杂视图），定位后可与专业人士沟通优化，咱们有DBA，所以我只要把问题定位到就行了。

　　下面展现一个我在优化时候遇到一个的状况：

　　优化前是查询一个复杂视图，由于查询没用到索引，单次查询了3.5秒，在生产环境还有遍历2次的状况，一个7秒。

　　优化后将视图改为存储过程，并经过业务了解到一个用户只会查询出一条记录，重复查的状况，耗时直接降到120+毫秒

优化经历

　　我刚完成这个需求二期上线，就收到加载慢的消息，整个优化过程并不是一步到位的，主要分了三步：

　　第一步，能马上可预见的，比较低级的优化了，并将列表加载改为异步，由于需求已经上线了，要先唬住用户。

　　第二步，把屡次创建查询和部分已经在测试环境很慢的语句。优化完了以后发到了生产，快了2秒多，可是仍然不理想

　　第三步，给全部有可能查询慢的地方都写上日志，后来定位到了好几个慢查询，其中上面是罪魁祸首。

　　发布上线后，从原来的11秒耗时，降到1秒到2秒，细心的朋友会看见，在加载列表有一段UpdateUserTaskStatus的代码，这个是在读页面作更新操做，具体缘由与分析放到下一篇进行讲解

结尾

 　  本篇主要讲解了我在优化页面加载性能过程当中一些经历，固然想优化到极致还有更多作法，例如完全的先后端分离，读缓存等等。

　　然而咱们须要在投入与产出比之间作出权衡，以有限的成本，使用朴实的技术，达到有效的目标效果。