前言

　　上一篇《.NET-記一次架構(gòu)優(yōu)化實(shí)戰(zhàn)與方案-梳理篇》整理了基本的業(yè)務(wù)知識(shí)，同時(shí)也羅列了存在的問(wèn)題，本篇主要是針對(duì)任務(wù)列表的頁(yè)面進(jìn)行性能優(yōu)化。

　　該篇主要涉及的是代碼實(shí)現(xiàn)上的優(yōu)化，實(shí)現(xiàn)上的問(wèn)題是戰(zhàn)術(shù)債務(wù)，也就是我們平常出現(xiàn)的各種BUG，這種問(wèn)題一出直接影響業(yè)務(wù)運(yùn)營(yíng)與系統(tǒng)運(yùn)作。

　　你永遠(yuǎn)想象不到同一條SQL相差個(gè)3.5秒鐘，遍歷兩次就導(dǎo)致了 3.5秒*2次 = 7秒的耗時(shí)。具體請(qǐng)看下文。

二八原則

　　有接觸過(guò)性能問(wèn)題的朋友應(yīng)該都了解過(guò)，一般性能瓶頸都是在某行代碼或者某個(gè)方法，而不是整一個(gè)代碼實(shí)現(xiàn)流程。

　　例如：遍歷計(jì)算、沒(méi)使用到索引的SQL語(yǔ)句、多余重復(fù)的接口請(qǐng)求等等。

　　以二八原則的思想來(lái)考慮，80%性能耗時(shí)由20%的代碼引起，因此我們處理原則就是具體定位，具體問(wèn)題，針對(duì)解決。

現(xiàn)象描述

　　任務(wù)列表頁(yè)面問(wèn)題主要體現(xiàn)于加載任務(wù)列表過(guò)慢的性能低效問(wèn)題，就如上一篇所說(shuō)的加載事件需要11秒！這種對(duì)于用戶來(lái)說(shuō)是不能忍受的，特別是以現(xiàn)狀JOB觸發(fā)的方式時(shí)效如此低，用戶多看兩次，估計(jì)就會(huì)有放棄該產(chǎn)品的沖動(dòng)。

　　因此我們需要遵守3秒鐘原則。

3秒鐘原則

　　現(xiàn)代人的生活節(jié)奏都很快，網(wǎng)頁(yè)間的切換速度也越來(lái)越快。所謂“3秒鐘原則”，就是要在極短的時(shí)間內(nèi)展示重要信息，給用戶留下深刻的第一印象。當(dāng)然，這里的3秒只是一個(gè)象征意義上的快速瀏覽表述，在實(shí)際瀏覽網(wǎng)頁(yè)的時(shí)候，并非真的嚴(yán)格遵守3秒。

　　因此，在設(shè)計(jì)互聯(lián)網(wǎng)產(chǎn)品的頁(yè)面時(shí)，用戶等待時(shí)間越少，用戶體驗(yàn)越好

優(yōu)化實(shí)施

　　任務(wù)列表頁(yè)面為以信息展示的讀操作為主，因此對(duì)于 I/O 密集型程序，問(wèn)題主要體現(xiàn)于兩點(diǎn)：

慢查詢語(yǔ)句

多次建立查詢

多次建立查詢

　　該問(wèn)題主要從代碼實(shí)現(xiàn)方式上解決，場(chǎng)景又分為兩種情況：

信息重復(fù)查詢

　　描述：函數(shù) A 查詢了一次 Users 信息，其函數(shù) A 的子函數(shù) B 又進(jìn)行了一次查詢了一次Users 信息。

　　解決方案：去除子函數(shù) B 的重復(fù)查詢，并提供參數(shù)由函數(shù) A 傳入

遍歷查詢

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

　　解決方案：先批量查詢，然后在內(nèi)存過(guò)濾。
　　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)
　　})

以上并不是什么特別牛逼的技術(shù)，但是往往是某些地方性能瓶頸點(diǎn)，而導(dǎo)致這樣的原因也只有一點(diǎn)，貪方便。上遍歷查詢的例子看出，兩種寫(xiě)法的代碼量的確差了幾行，但是在實(shí)際使用場(chǎng)景中性能會(huì)差幾倍，而且隨著業(yè)務(wù)的增長(zhǎng)其差距越發(fā)的明顯。

慢查詢語(yǔ)句

　　對(duì)可能出現(xiàn)慢查詢的語(yǔ)句的進(jìn)行日志埋點(diǎn)記錄耗時(shí)（特別是手寫(xiě) SQL 與復(fù)雜視圖），定位后可與專業(yè)人士溝通優(yōu)化，我們有DBA，因此我只要把問(wèn)題定位到就好了。

　　下面展示一個(gè)我在優(yōu)化時(shí)候遇到一個(gè)的情況：

　　優(yōu)化前是查詢一個(gè)復(fù)雜視圖，因?yàn)椴樵儧](méi)用到索引，單次查詢了3.5秒，在生產(chǎn)環(huán)境還有遍歷2次的情況，一個(gè)7秒。

　　優(yōu)化后將視圖改成存儲(chǔ)過(guò)程，并通過(guò)業(yè)務(wù)了解到一個(gè)用戶只會(huì)查詢出一條記錄，重復(fù)查的情況，耗時(shí)直接降到120+毫秒

優(yōu)化經(jīng)歷

　　我剛完成這個(gè)需求二期上線，就收到加載慢的消息，整個(gè)優(yōu)化過(guò)程并非一步到位的，主要分了三步：

　　第一步，能立刻可預(yù)見(jiàn)的，比較低級(jí)的優(yōu)化了，并將列表加載改成異步，因?yàn)樾枨笠呀?jīng)上線了，要先唬住用戶。

　　第二步，把多次建立查詢和部分已經(jīng)在測(cè)試環(huán)境很慢的語(yǔ)句。優(yōu)化完了之后發(fā)到了生產(chǎn)，快了2秒多，但是仍然不理想

　　第三步，給所有有可能查詢慢的地方都寫(xiě)上日志，后來(lái)定位到了好幾個(gè)慢查詢，其中上面是罪魁禍?zhǔn)住?/p>

　　發(fā)布上線后，從原來(lái)的11秒耗時(shí)，降到1秒到2秒，細(xì)心的朋友會(huì)看見(jiàn)，在加載列表有一段UpdateUserTaskStatus的代碼，這個(gè)是在讀頁(yè)面做更新操作，具體原因與分析放到下一篇進(jìn)行講解

結(jié)尾

?　? 本篇主要講解了我在優(yōu)化頁(yè)面加載性能過(guò)程中一些經(jīng)歷，當(dāng)然想優(yōu)化到極致還有更多做法，例如徹底的前后端分離，讀緩存等等。

　　然而我們需要在投入與產(chǎn)出比之間做出權(quán)衡，以有限的成本，使用樸實(shí)的技術(shù)，達(dá)到有效的目標(biāo)效果。

原文地址:?https://www.cnblogs.com/skychen1218/p/10320994.html

.NET社區(qū)新聞，深度好文，歡迎訪問(wèn)公眾號(hào)文章匯總 http://www.csharpkit.com

總結(jié)

以上是生活随笔為你收集整理的.NET-记一次架构优化实战与方案-前端优化的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。