很久前，在512M內存+Access的VPS里，寫過了一個經典的秋色園技術原理解析系列。
后來的某一天，換上了1G內存+MSSQL2000，秋色園又跑過了一個多年頭。
之后，秋色園和
CYQ.Data，也在一直默默的優化和改進，只是沒寫什么文章分享分享。
秋色園的架構，基本上從簡單到復雜最后又回歸簡單，不斷做着減法，去掉了好多以前用於減輕負載的算法，包括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：如何對網站進行負載測試:
分布式網站負載壓力測試工具：
點擊下載
后話：
硬件能頂半邊天：一台好的服務器，程序寫的爛一點，不做任何優化，也能跑的瀟瀟灑灑。
軟件能頂半邊天：好的優化機制和架構，窮的服務器也能跑個安安穩穩。
現實時，只有超過了那半邊天，你才會去想另一半的重要性。