點擊上方藍字關注“汪宇杰博客”

導語

去年年底我寫了一篇《我的 .NET Core 博客性能優(yōu)化經(jīng)驗總結》，但后來還發(fā)現(xiàn)有一處遺漏需要補充。我們一起來看看~

犧牲空間換時間

我們知道軟件設計只有高手才能做到又小又快，像我這種普通程序員通常只有兩種方案：犧牲時間換空間、犧牲空間換時間。那么在需要追求性能的情況下，可以做一些空間上的犧牲。例如，數(shù)據(jù)庫可以保存冗余數(shù)據(jù)。

犧牲數(shù)據(jù)庫空間

在我博客中，我需要在文章列表頁面顯示內容摘要，這個摘要來源于整篇文章的前400字。在我的舊版 .NET Framework 博客里，這個操作每次都是 SELECT 完整文章內容后用 Substring() 截取前400字，由于用了 EF，很難在 SQL 里完成這個截取，因此白白消耗了很多時間和網(wǎng)絡傳輸成本。而在 .NET Core 重寫的博客中，我調整了這個設計，在文章表里新加了一列，專門用于存儲前400字的文章摘要，而摘要的內容會在新寫文章或者編輯文章的時候計算完成并存儲到數(shù)據(jù)庫，這樣我顯示文章列表的時候就不需要去 SELECT 完整的文章內容。雖然這樣的設計嚴格來說肯定不滿足數(shù)據(jù)庫的那些個范式，但充分提高了此處的性能。

在企業(yè)系統(tǒng)里，這種做法也比較常見。如果有開銷比較大的計算才能得出的結果，并且結果不會變，那么不需要每次都去算，而設計成算完就存儲在數(shù)據(jù)庫里，以提高性能。

犧牲文件系統(tǒng)空間

我博客中，RSS/ATOM/OPML 等訂閱源在以前也需要每次都去數(shù)據(jù)庫取數(shù)據(jù)計算完成后，輸出到客戶端。然而這類數(shù)據(jù)也有個特性，就是幾乎不會變。于是我就設計成第一次用戶訪問的時候，將計算結果生成 XML 文件緩存到臨時目錄，那么后續(xù)用戶訪問的時候就不需要 hit 數(shù)據(jù)庫了。僅當文章內容有修改的時候，drop 掉緩存的文件，讓用戶下次請求時重新生成。

本文小結

在系統(tǒng)設計中，不要過分遵守理論，比如數(shù)據(jù)庫范式，要具體分析自己遇到的業(yè)務情況，并做調整，世界上沒有可以完美復制的“最佳實踐”，只有適合自己業(yè)務的才是最佳實踐。

懶，越懶越好！充分分析業(yè)務，明確哪些數(shù)據(jù)不容易變，可以緩存就緩存，文件也好，內存也好，根據(jù)需要自己設計。能不要去調用數(shù)據(jù)庫的就盡量不要去用，因為通常系統(tǒng)最慢的環(huán)節(jié)就是在調用不同的API和數(shù)據(jù)庫通訊上。

其他性能優(yōu)化事項歡迎參考前篇《我的 .NET Core 博客性能優(yōu)化經(jīng)驗總結》

總結

以上是生活随笔為你收集整理的我的 .NET Core 博客性能优化经验补充的全部內容，希望文章能夠幫你解決所遇到的問題。

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