秋色園QBlog技術原了解析：性能優化篇：位元組、緩存、并發(十二)

文章回顧：

附章：

上節回顧：

本節介紹：

優化一：位元組

為了減少傳輸的位元組，通常都會采取一些壓縮[html,js,css]

1：壓縮html：秋色園采用将Html當xml方式加載的手段，預設就是無空格狀态，是以天生就有這優勢，連GZip壓縮也省了。

2：壓縮CSS：本人對CSS不精通，沒辦法整體優化，利用VS格式化：一條樣式格式化成一行,再删除一些沒用到的CSS樣式，勉強少了幾K。

3：壓縮js：秋色園沒有用js，是以沒這方面的開銷，省力又省心。

優化二：緩存

在長久的開發過程中，秋色園中形成了以下幾種緩存：

1：緩存表架構：CYQ.Data 資料架構的預設緩存

2：緩存html架構：未經處理的原始html界面,即預設的皮膚的html[秋色園的緩存機制]

3：緩存經過處理的html架構：包括css路徑處理，語言翻譯等，但不包括資料填充，[秋色園的緩存機制]

4：緩存頁面：緩存最後的html[秋色園的緩存機制]

緩存是層層遞進的，有了以上的幾層緩存保障，性能是刷刷的上去了，頁面打開也很快。

三：負載來臨，問題出現，失控的緩存

秋色園的運作環境：國外Godaddy的虛拟主機的子目錄+Access資料庫

天生不佳硬體的條件，讓過往的一些優化在這裡顯的有些脆弱，堅持不了多久，文章上到幾萬，性能又再次走到邊緣，首頁時快時慢，緩存似有似無，并發寫把站點折騰的一度打不開。

主要表現在以下幾個大方面：

1：并發寫操作：Access本身在并發寫時經常有死鎖發生，很糾結。

2：緩存的過期：幾乎是不可控的，有時打開慢[緩存失效了]，有時打開快[剛好緩存已起來了]。

3：翻頁的速度：在通路量少的頁面，特别是翻頁，由于沒有緩存的照顧，每次打開都3-5秒，讓人感覺一個字：慢。

優化四：Access的并發控制處理

需要找到站點經常性寫資料的操作點：

1：使用者背景：

解決手段：通過增加Lock來避免并發

由于所有的更新删除插入，都執行的：ExeNonQuery函數，

是以隻要以在底層這函數裡加一個可配置的項，來決定啟用Lock，解決。

2：高頻率的文章與使用者通路計數：

解決手段：通過一些手段來減少更新的頻率。

問題：如果每次使用者通路，都執行更新計數，這對Access來說就太可怕了：會造成經常性的死鎖，通路也會受影響。

采用的措施：采用了緩存計數+機率性更新，來更新到資料庫，目前有效的解決了這一問題。

副作用：就是由于緩存的丢失，會丢失小部分的統計數字，不過使用者通路量，并不需要太準确的數字，是以此手法還算合适。

優化五：掌控全局緩存，合理調優

緩存失控了？

緩存怎麼用：

cache.Add(key,obj,times);//将一個對象存入緩存一段時間。

緩存何以失控？

試想下，緩存的一段時間你是怎麼定的？

敲代碼時就給了想當然的時間，對不?不對？不？對？不對？

好了，說問題，正常情況下，緩存是怎樣失控的？

1：不知道緩存的對象在記憶體中的使用情況，缺少同步與清理機制。

2：沒用的緩存占了大量記憶體、記憶體回收看不見、性能優化全靠猜猜猜。

失控的效果與後果？

效果：

公司的伺服器，配置高，記憶體大，緩存随一放，時間值設大，問題就不大，效果良好見效快。對外可以展示自己做的站點性能高，通路快，高手就這樣造成出來了。

後果：

窮人的，用的虛拟主機，或VPS，記憶體就一丁點，資源很有限，再亂扔記憶體，對性能提升反而無益：記憶體不斷的在超出，回收，超出，回收中循環。

結果：緩存成了虛設，站點好一會，慢一會，天天糾結中循環。

秋色園緩存早期情況：

失控狀态，頁面時快時慢，緩存時有時無，有人說慢有人說快。

可控的緩存設計

一個良好的系統，必須對緩存的使用情況有所掌控，再根據實際環境做适當緩存調整政策，進而同樣的資源，有更多的發揮。

秋色園緩存目前情況：

為了全局綜合性的提升緩存性能，急需要對全局緩存有所掌握，才能做到相對合理的調優。為此，對CYQ.Data的緩存機制做了一些優化與調整及資訊輸出，以掌握全局情況。

這裡截一張秋色園的緩存全局情況圖：

如上圖：

這是秋色園整站的緩存資訊，通過這樣的資訊表，即可掌握哪些緩存是用的多，哪些緩存用的少，可以合理的設定時間及清除政策。

其它：

對的！！！版本要求？近期會釋出新版本，将帶此功能，敬請關注。

總結：

     本文轉自cyq1162 51CTO部落格，原文連結：http://blog.51cto.com/cyq1162/560245，如需轉載請自行聯系原作者