前言：
標題為啥要加個“小”，只因為上一篇文章“
小網站架構優化：從100並發抗到4000並發”，帶了個“小”字，所以這篇也順流加個“小”了。
大意“小”是特指秋色園（流量小，服務器配置低）的意思，畢竟文章都是從實戰后才寫出來的。
關於現實網站的抗並發實情：
由於每個網站的性能點，最后都離不開抗並發這一話題。
也許，網站本身並沒有那么多並發訪問，但為何還要抗並發？
因為現實不是每個人都是善良的，商業競爭也很激烈，競爭對手間時不時的互相攻擊網站也很普遍。
昨天才一網友向我說起，他朋友的網站，逢周一就會被競爭對手攻擊，導致業務無法開展，換服務器也無濟於事。
所以，提升網站的抗並發能力，除了抵抗用戶的高峰期訪問，也是是自我網站保護的一種手段。
什么樣的站點能抗的起高並發？
若除卻外部帶寬等因素造成的外部影響，則內部答案只有一個：靜態網站。
靜態網站何以能抗高並發？
因為靜態頁面據說在操作系統內核級就能緩存數據並做出響應，所以抗並發能力理論上是最強的。
所以，你看看電商網站，除卻技術背后的實現，你能看到的頁面，多數是靜態頁面。
所以技術的背后是Java還是.net還是php，看似就不是那么的特別了。
當然了，也不是所有站點都適合靜態化，所以技術架構優化顯的特別的重要。
根據某網友提供的數據，僅供參考：
CSDN首頁的文章：2000並發以下掛了，這塊是java提供服務。
而CSDN的博客：能頂好萬級的並發，這塊是ASP.NET提供服務。
而CSDN的論壇：能頂好幾十級以上的並發，這就是靜態化的結果。
所以那篇很火的“去.NET化的文章”，可能是作者個人意淫，
當然了，這些數據可能也是意淫的結果，不一定所屬事實。
所以，要提高抗並發數，高配的服務器不是全部，還需要合理的代碼架構優化：
本次實踐分離方案的背景：
在秋色園系統的優化文章中，都似多似少的提到了搜索這塊引發的CPU命案。
某天，我想起了“
IIs 網站應用程序與虛擬目錄的區別及高級應用說明”這篇文章的內容。
有了想把搜索獨立出去的想法，這樣即使搜索掛了，也不影響網站訪問，更不用擔心搜索引發的CPU命案。
構思中：
於是三七二十七，就開始想了：
目前秋色園的URL搜索這一塊為：www.cyqdata.com/search/類型/搜索內容。
而文章的關鍵字（一般博客為設置為tag，引到文章，而我是引到搜索區）。
想了兩種方案：
A：是弄個二級域名，建個網站來運行，這個需要動點代碼：
這種方案，要修改URL變為so.cyqdata.com/類型/搜索內容，看似改動不少，需要調整URL機制和301處理，預計整體在30-60分鍾內應該可以解決完。
這種方案的好處是，后續擴展可以部署到其它服務器。
這種方案的好處是，后續擴展可以部署到其它服務器。
B：直接使用子應用程序，可以不改動代碼，直接把搜索這塊分離獨立子應用程序運行：
這種方案，代碼不用改，因為根據search建立子應用程序即可。
這種方案，一般就局域服務器只能在局域網內了。
這種方案，一般就局域服務器只能在局域網內了。
方案選擇：
綜合秋色園目前的情況，也就一台VPS。
兩個方案的區別就在於動代碼和不動代碼了。
后來我選擇了不動代碼，因為實際的效果幾乎是一樣的，所以就不動代碼了。
方案二實施過程：
1：在IIS 6 里新建一虛擬目錄search，創建右鍵屬性，應用程序名那里對應的按鈕點擊“創建應用程序”然后虛擬目錄就轉化為應用程序了。
2：項目路徑還是原來的項目路徑，然后設置新的應用程序池，最終如下圖：
總結：
一般一個項目大了后，或者邏輯變的復雜后，往往的解決方案就是分解成子項目。
而分解的方案：一般是根據域名，或首頁節點目錄。
后來思緒了一下，比如目前博客的URL是：xxx.com/cyq1162/admin/...
如果一開始考慮把它設計成：xxx.com/admin/cyq1162/...
這樣是不是也就可以輕松的把博客的前后台分離開來。
當然了，分成多個進程，是需要思考，是否有涉及直接的通訊。
文本就介紹到這里了，僅提供一種參考方案。