Java之網站優化
- 2020 年 4 月 2 日
- 筆記
本博客從今年年初開始，其實已經完成了基本功能。隨着偶爾寫兩篇文章，本站訪問速度越來越慢。最開始使用的是騰訊雲的最基礎雲服務器，配置為：共享CPU、512M、Unbuntu服務器，每次打開服務器，發現CPU和內存使用率經常達到了100%，基本滿載運行。還經常報內存溢出異常。
後來，升級了服務器，內存變為了1G，CPU也變成了單核。但是網站的訪問速度還是讓人不能忍受。今天，博主終於不能忍了，仔細分析了下代碼和服務器。主要從以下兩個方面進行了優化，大大提高了網站訪問速度：
（1）坑爹的Hibernate，from查詢。
雖然博主早就明白數據庫查詢的時候，堅決避免select *。但是博主還是犯了迷信框架這個錯誤，Hibernate默認推薦的是 from 對象。這種處理方法無疑將所有查詢默認為select *，這簡直是一種愚蠢的做法。特別是當數據庫中存儲有大文本字段的時候。本博的文章才16篇的時候，已經慢的不行了。
解決辦法：查詢部分字段
這種方法需要在實體類中構造指定字段的構造方法，查詢語句中使用：select new Blog(b.id,b.title,b.content2,b.author,b.pubDate,b.click) from Blog b。否則，查詢出來的集合對象不能直接轉換為List對象，Hibernate的面向對象功能將失去其優勢。
（2）對特殊字段進行處理。
由於博客中的內容字段是longText類型，每次直接從數據庫中取出來的時候，將大大降低數據庫的IO。雖然Hql自帶了許多函數，比如substring函數，可以直接操作數據庫內容。但是，這樣的結果是：直接導致查詢出來的結果是Object數組。有意思嗎？轉換起來又麻煩得要死。沒辦法，只好，存儲一個冗餘字段content2，每次更新的時候，取content2=content.subString(0,300)。
（3）網站圖片的處理。
對於圖片，我們有兩種處理方式，存儲在數據庫中，或者把鏈接地址存儲在數據庫中。前者，使用方便，我們可以直接把圖片複製到博客中發表，非常簡單，不用轉換。缺點是：早期數據庫不推薦，現在數據庫性能還好，無所謂。後者方法，每次需要使用圖片時，先上傳到服務器上，拿到鏈接地址，數據庫中只存儲鏈接地址。這種方法麻煩了點，特別是圖片多的時候。
好吧。。博主不從使用的便捷性考慮問題，來點程序員的思路。圖片存儲在數據庫中是二進制數據，並且這個量相對於文本還是相當大的。如果我們需要對數據庫內容進行搜索、全文檢索時，那麼就非常不推薦把圖片直接存儲在數據庫中，否則會嚴重影響文本檢索結果。如果需要對圖片進行特別處理的話，比如圖片檢索的話，那就需要提取出圖片的關鍵性特徵等信息，另外存儲了，這樣的信息存儲在數據庫中也比較好。
從性能上來講，大家可以比較下這相同的兩篇文章：http://www.webank.pw/blog_show.action?blog.id=6和http://www.webank.pw/blog_show.action?blog.id=21的訪問速度。這篇文章內容總共包含17張圖片，共600KB大小。但是訪問速度已經可以明顯區分了。前面一篇文章的圖片是存儲在數據庫中的，後面一篇是存儲在服務器的。後者明顯快於前者。至於原因，這裡各種分析就略了，什麼服務器性能啊、服務器帶寬啊、客戶端網速啊、圖片傳輸速度啊、圖片顯示速度啊。。。。。大家感興趣的可以進行專業分析的。
經過以上處理後，本站的訪問速度總算是正常了。不再半天沒反應。
