前言：
很久前，在512M記憶體+Access的VPS裡，寫過了一個經典的秋色園技術原了解析系列。
後來的某一天，換上了1G記憶體+MSSQL2000，秋色園又跑過了一個多年頭。
秋色園的架構，基本上從簡單到複雜最後又回歸簡單，不斷做着減法，去掉了好多以前用于減輕負載的算法，包括AOP+SQLite分壓和文本分壓等機制，還有一些緩存式算法。
好多時候，硬體不給力，這時候就會被逼着把整個系統架構複雜化。
一當硬體給力時，系統輕裝上陣，架構可以更簡單。
因為本質就是請求+傳回（硬體能加速的，軟體就不用搞太多算法了）。
下面在分享一下我記憶中還記得的秋色園關于負載測試的起緣：
1：某天，我發現秋色園CPU經常會跑滿100%：
經過一年的歲月，不知覺的最終被我發現是搜尋引擎引發的（雖然寫過IIS日志分析工具，但是我自己都很少用，幾乎沒怎麼用，一用沒想到找到問題了）。
我發現秋色園的關鍵字（Tag），由于是直接連結到搜尋，而搜尋這塊是全表的like搜尋，沒做緩存的優化，是以搜尋引擎心情好時就把它弄挂菜了。
2：某天，某人用幾百個并發，把秋色園又搞到CPU百分百了：
我很疑惑，秋色園幾乎都是半靜态+緩存，除了隊列緩存式更新通路計數，和除了背景，不可能頂這點并發就挂了。
通過檢視IIS日志，我從日志裡發現，是由于URL引發的：
由于秋色園是根據URL緩存的，對方的并發通過在URL後面補充一些随機參數，導緻每次請求的URL都不一樣，結果系統每次會重新讀取并生成Html，導緻CPU飄起來。
解決方法就是重整所有的URL連結和對應的緩存機制了。
3：某天，我也玩起了負載工具，自己時不時的把秋色園弄到CPU百分百：
下面分享下，在負載推力下，對秋色園後續折騰的幾個優化方案：
經過不斷的負載測試，秋色園順路把一些常見的優化手段也用上了：
1：分離靜态資源域名：static.cyqdata.com
架構處理過程：
1：把模闆加載和圖檔處理的，都給處理到另一個域名。
2：新開一個網站，綁定static.cyqdata.com域名，位置仍指向原來的位置。
3：由于是靜态站點，可以關掉和.net無關的所有東西。
這樣變化後，圖檔的負載就是天與地的變化：
如果沒有分離出來，仍經過.net解析後再傳回圖檔，測試1-2千個并發CPU就近滿了。
經過分離，關掉和.net相關的資源後，跑了5000以上并發，CPU和記憶體也沒怎麼動靜。
主要自己三台機最多隻上到這5K左右的并發數，不能往上再測試，但是差距已經很明顯了。
2：Http 304：這是用戶端緩存的應用：
除了伺服器緩存，用戶端緩存也是另一個重點，除了一些靜态資料處理緩存，動态資料也适時用上304。
如：秋色園上有一些動态的檔案“下載下傳次數”：
一般的程式，檔案下載下傳都是和文章内容分開的，單獨提供下載下傳。
如上，我需要在文章内容裡提供下載下傳，又要考慮下載下傳次數機制，用上了圖檔機制，通過動态一個請求傳回了圖檔資源。
由于下次數次實時性不強，而且變化少，通過來點手段，也可以304緩存。
3：關掉不常用的Modules:
如果你重寫過URL，或看過秋色園技術原了解析關于URL重寫這塊文章，下面代碼應該會熟悉：
通過調試，看下圖：秋色園的Modules隻剩下3個，那時因為其它的沒用的都關掉了。
本來Session子產品也是要關掉，突然發現OAuth2裡用到了，就保留了。
看下圖還會發現一段注釋的for語句，是列印出預設系統帶的十幾個Moudules。
關掉也很簡單，web.config配置：
<httpModules>
<add name="UrlRewrite" type="Web.UrlRewrite.UrlRewrite,Web.UrlRewrite" />
<remove name="OutputCache" />
<!--<remove name="Session"/>-->
<remove name="WindowsAuthentication" />
<remove name="FormsAuthentication" />
<remove name="PassportAuthentication" />
<remove name="RoleManager" />
<remove name="UrlAuthorization" />
<remove name="FileAuthorization" />
<remove name="AnonymousIdentification" />
<remove name="Profile" />
<remove name="ErrorHandlerModule" />
<remove name="ServiceModel" />
<!--<remove name="UrlRewrite"/>-->
<!--<remove name="DefaultAuthentication"/>-->
</httpModules>
4：盡早關閉資料庫連結：
以前喜歡這樣寫代碼：
using (MAction action = new MAction(U_QBlogFileEnum.Blog_File))
{
action.SetSelectColumns(Files.ID, Files.Hits, Files.FilePath);
if (action.Fill(id))
{
Document.Load(action.Data);
。。擷取資料庫資料處理一些業務邏輯顯示到界面。
}
}
這種壞習慣，導緻資料庫連結會根據業務的時間延長了關閉連結，導緻并發性能下降，平時看不出來。
改進：
MDataRow row;
using (MAction action = new MAction(U_QBlogFileEnum.Blog_File))
{
action.SetSelectColumns(Files.ID, Files.Hits, Files.FilePath);
if (action.Fill(id))
{
row=action.Data;
}
}
if(row!=null)
{
Document.Load(action.Data);
。。擷取資料庫資料處理一些業務邏輯顯示到界面。
}
把邏輯放到外面，提前關閉連結後再去處理事情，并發時性能會提升不少。
5：Web園的抗并發能力：
基于不斷的優化改進，秋色園從100個并發挂菜-》基本優化-》到1000個并發挂菜-》經過架構調整優化-》抗到2000個并發左右。
最後，還有一個招，就是IIS的Web園，通過允許的設定了2個程序，發現能抗到4000并發，雖然CPU接近100%，但仍能正常通路，可見Web園的确是個奇招。
開啟Web園，意味着多程序負載，當然Session預設的模式就不能用了。
如上所說，同樣的硬體配置：從100個并發，到4000個并發，改動并不多，路也并不長，但是常人又知多少。
以上的伺服器環境，都是美國VPS 10M帶寬CPU雙核，配置如下：
6：如何對網站進行負載測試:
後話：
硬體能頂半邊天：一台好的伺服器，程式寫的爛一點，不做任何優化，也能跑的潇潇灑灑。
軟體能頂半邊天：好的優化機制和架構，窮的伺服器也能跑個安安穩穩。
現實時，隻有超過了那半邊天，你才會去想另一半的重要性。
本文轉自cyq1162 51CTO部落格，原文連結：http://blog.51cto.com/cyq1162/1198761，如需轉載請自行聯系原作者