.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的代碼，這個是在讀頁面作更新操做，具體緣由與分析放到下一篇進行講解

結尾

 　  本篇主要講解了我在優化頁面加載性能過程當中一些經歷，固然想優化到極致還有更多作法，例如完全的先後端分離，讀緩存等等。

　　然而咱們須要在投入與產出比之間作出權衡，以有限的成本，使用樸實的技術，達到有效的目標效果。