標題：新手筆記-網站加速：不是太少，而是太多
關鍵詞：網站開發、網站加速方案、合理選型
8月30號： 回憶進行網站加速步驟，真是百感交集！
很長時間沒有寫筆記了，網站的工作的確是非常瑣碎。不過真的要做好實在是很難，下面這個筆記斷斷續續寫了兩個月，很多想法又都發生了變化，所以寫的很亂，請大家對付看吧：）
網站的技術工作其實涉及的面非常廣。從網站信息發布的運行平臺的選擇到采編入庫的設計與開發，都需要進行很多的調研與方案定制。綜合的進行不是簡單的幾篇筆記就可以完成的。這次先對加速的方案進行簡單的說明。目前所處的網站采用零零總總的加速方式有很多，下面是對這些加速方式的簡單說明。
解決網站的壓力問題，是所有商業化的網站都要考慮的事情，從對訪問量的預期，以及不同時段壓力的不同，都要進行綜合的考慮。硬件是最重要考慮的方面。軟件同樣也非常重要。定義的框架是否合適，物理上的數據庫是否將讀寫進行分離，這些都是在網站的設計階段要考慮的部分。但遺憾的是，最初網站的設計者并沒有將這樣都考慮進行，而是將問題留到的上線之后再進行調整，這就導致了上線之后的很大壓力。在我們的新版網站剛上線的時候，訪問高峰期數據庫服務器的CPU負載一直在80%以上，網站服務器的CPU負載也保持在平均70%。加速、加速、再加速就成為領導嘴中的問號與感嘆號。
有很多成功的經驗可以從網上找到，當然也不能放過改版之前網站的成功經驗。于是我們找到了下面幾種加速方法（雖然這個時候再出想有什么加速方法已經非常晚了，但也還是要進行下去。）
下面是幾種用上的加速方法
1. ASP.net本身的頁面緩存技術與數據緩存技術
各種的網站開發語言都會有自己緩存技術，可以在開發過程中進行運用。頁面緩存是將頁面通過在ASPX的頁面上用<%outputcache….%>寫上緩存的時間，緩存的方案。數據緩存則可以將幾乎所有ASP.net支持的變量按照你所想要的方式緩存起來，以提供給程序調用時使用。
2. 針對復雜的查詢建立索引
除去一開始進行的設計時已經建立好的索引，你可能還需要在網站對數據庫訪問很大時，用SQL的事務跟蹤器去找出查詢語句的瓶頸，并為之想出相應的方法，比如用存儲過程，為還沒有建立索引的表建好索引，多建幾張臨時表，等等。由于我數據庫方面不是很熟，這里就不多說了。
3. 將DB的讀寫進行分離
這是前輩們傳下來的寶貴經驗，同時對SQL數據庫進行讀寫操作是非常慢的一種數據庫訪問方式，比較好的方式是根據讀寫的壓力不用，分別建立兩類結構完全相同的數據庫服務器，將負責寫的那類服務器的數據定時復制給負責讀的服務器。
4. 將DB與Web服務器分離
DB與Web服務器在一臺機器上會使訪問速度變慢。所以要使得網站加速，這方面也需要進行考慮。
5. 將常用的數據，以及更新比較少的數據形成靜態文件
網站的開發，有一些數據變化量是非常小的，比如詳細文章頁面，采編人員將其輸入進我們的系統之后，幾乎不進變化。這種情況下，可以采用將常用的數據定期的生成靜態的數據文件的方法。來對網站進行提速。程序可以通過訪問靜態文件的方式，來達到提高網站整體速度的目的。
這里要對這個方式進行簡單的說明，數據庫情況好的時候，對數據庫的讀寫是比對文件的讀寫要快的，但是如果大量的對數據庫進行讀寫，或是每一次都會有比較復雜的邏輯對數據庫進行讀操作時，并且在實時性要求不太高的情況下，不如將這些復雜的操作每次的生成靜態的數據文件，這樣可以使得程序每次只需要對靜態文件進行讀操作，可以達到減輕數據庫壓力的效果。
還有一個好處是，萬一數據庫發生無法讀取的數據故障，那么網站的實際上是可以運營在這些靜態的數據文件之上的，在系統運行并不穩定的運營初期，這樣的數據文件是非常有意義。這種加速方式可以對應到上面的Asp.net的數據緩存。由于所有的數據都被存儲成標準的XML格式數據文件，所以這種數據緩存方式不僅僅可以在Asp.net的應用程序使用，也在可以提供給其它的一些應用使用，
6. 將被訪問的動態頁面通過加速程序定時生成靜態頁面，以提供給用戶一個靜態的頁面快照。
終級加速方案？可以將動態頁面定時讀出，另存為靜態頁面。與Asp.net的頁面緩存相似，唯一區別是頁面加速可控度高，而且如果Asp.net無法執行，靜態頁面也可以很方便的在其它的HTTP server上使用。
以上所說的是在Asp.net+SQL的環境下可以采用的網站加速的方式。可以老實的告訴大家，第5種與第6種方式都是在系統運行不穩定的情況下，或是對IIS6沒有信心的情況下的產物。我個人并不推薦大家采用。
說完了目前網站所采用的方式之后，想與大家分享一下運用這些加速方式之后的體會，以及得到的一些經驗與教訓。希望大家在以后的網站開發過程中不要重復同樣的錯誤。
l 加速---不是太少，而是太多
可以從上面所說的得出一個結論，如果一個網站在設計與運行的過程中，即有數據庫級的加速，又有業務邏輯層的加速，還有最終頁面級的加速，那么存在問題就會是，是不是所有的加速形式都必須要存在？是不是有你已經做了一些沒有意義的費工作？實際上，當我重新回頭去看堆積在網站中的所有加速方法時，不禁產生一堆疑問：為什么在我已經定義好了頁面緩存之后還要有一堆循環生成的數據文件？為什么數據庫的索引都建好之后還要有數據級的緩存？什么情況下有了頁面緩存還需要有頁面加速？……，當一大堆的為什么出現在你面前時，你才能夠了解，去給一個網站加速的方式不是太少，而是太多，你所要做的是選擇出那些最少，最合適的方案來處理你所要面對的問題，而不是慌慌張張的將你要知道的所有的加速方案都堆砌在網站上，這樣得到的結果可能就會是網站的更新效率低下，維護費用增加，不確定性也在增加，等等。所以，記住，加速的方法，不是太少，而是太多，要合理進行選擇。
l 不要因為一次錯誤而進行否決某種方案
如果你試了一下數據加速的方法，發現你的網站的訪問速度沒有得到很好的提高，那么你會怎么樣？放棄后找一條新的路子，還是對仔細研究你的這次試驗的結果究竟說明了什么？看看我上面的說的，當你有太多的選擇時，你可能會對每一項都并不看重，那么你錯了，我的項目組在選擇加速方式的時候走過一些回頭路，這些回頭路都是由于我們提出一個好的方案A，試一下，沒有太好的效果之后馬上放棄，轉到另一次的實驗，通過一段時間的運行，突然又發現方案A不好使的原因是由于其它的原因，而不是方案A本身的原因，再回頭使用方案A，又花費很多的時間與精力。所以在可以選擇方案很多的情況下，也一定要慎重的考慮，而不要因為一次錯誤而進行否決某種方案。
總而言之，網站加速一定是要在開始的設計階段計劃好，而設計之后的調整就是屬于很痛苦的，這個就與面向方面編程（AOP）所說的問題有一些共同的地方。AOP的問題回頭再與大家討論吧。
加速的部分就是這些想法了，歡迎大家與我進行溝通，我的MAIL地址是viktoryu@hotmail.com