前言：
很久前，在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;
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：如何對網站進行負載測試:
後話：
硬體能頂半邊天：一台好的伺服器，程式寫的爛一點，不做任何優化，也能跑的潇潇灑灑。
軟體能頂半邊天：好的優化機制和架構，窮的伺服器也能跑個安安穩穩。
現實時，隻有超過了那半邊天，你才會去想另一半的重要性。