歡迎光臨
每天分享高質量文章

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

結尾

    本篇主要講解了我在優化頁面加載性能過程中一些經歷,當然想優化到極致還有更多做法,例如徹底的前後端分離,讀快取等等。

  然而我們需要在投入與產出比之間做出權衡,以有限的成本,使用朴實的技術,達到有效的標的效果。

赞(0)

分享創造快樂