由于上文有介紹了一些前因後果和中間過程及基礎的内容，是以怎麼發生的，中間大體做了什麼檢測，就不重複寫了，下面寫一些事情的後續發展。
在解決完上文說的，搜尋引擎引發的命案後，有網友給秋色園做了下壓力測試，連結數直上1-2千，導緻cpu挂了。
一：url緩存可能存在的攻擊命案：
當時我一路正遠端用sql事件探查器和性能計數器觀看着，發現iis并發連結數直接上千，不停的産生sql語句， 導緻資料庫占用cpu直接滿了，網站挂了打不開。
從這裡，我發現了系統上存在一些邏輯上的不和諧：
比如：http://www.cyqdata.com/tech/cate-19，秋色園網站的緩存，基本上是基于url來緩存的。
而對方發起的壓力測試，則并發産生了數百個： http://www.cyqdata.com/tech/cate-19-nxxxxxxx這樣的網址。
由于url的變化，是以不停的産生新的頁面查詢，造成資料庫不斷的查詢，持續的并發查詢資料庫cpu直接滿了，挂了。
對于這個問題，我進行了全面的url參數處理，在未讀取資料庫之前，就判斷參數的合法性，和邏輯上的調整，把跳轉檢測的函數放在前面，其它讀取的放後面，這樣無效的位址也不會引發不必要的資料庫語句查詢或邏輯。（全站有好幾個，都存在這種情況，都同樣的方式處理了）。
根據這個規則，大夥就要注意了，根據url位址緩存的邏輯，或動态生成靜态頁面邏輯的，還是要細心的檢測一下。
二：dz論壇的小檢查
現在有好多論壇，好多個人站都運作在vps或虛拟機上，我跑過去看了下，試圖想找到一些動态處理的頁面，來進行下壓力測試，結果發現除了登陸發貼等少數動态的，幾乎全站靜态。
通常的說，搜尋這塊，通常都是動态的，而且也比較消耗時間的，我一搜，發現，真聰明，dz直接引用了soso的搜尋服務，把壓力轉移了。
三：網站并發壓力測試工具
好多人問題是用的什麼工具，網友用的是apache自帶的ab.exe，隻要安裝了apache，目錄下就有這工具了，一條簡單的指令行就能簡單的對某網址進行壓力測試。
不過有個限制，一般最多是64個并發，比線上并發測試網站預設提供的15個免費并發好多了，linux下有幾篇文章有說修改并發數的，卻沒找到在windows下怎麼修改并發數上限的方法，有知道的說一聲。
四：一個未知的線程死鎖：
這個問題，在本地時測試時出現過幾次，出現的時候，我也很積極的dump，通過processxp工具也能看到2個線程各占20%，持續時間長，就是不下來，然後沒有更多資訊了。
dump是個悲催的事，真心不擅長，來來回回幾個指令，就是不見啥資訊，幾年前我dump過一次，幾年後，還是dump在那水準，悲催的歲月，發現不了問題所在。
折騰許久許久後，放棄了，後來一直在大力重構，好多代碼邏輯删除了，重寫了。
之後，這問題也失蹤了，許久也沒再出現過，不知道是不是意外的存在被我删除的代碼中。
五：系統磁盤空間不足引發的命案：
剛剛有微網誌使用者給我留言，說秋色園打開報錯，提示硬碟空間不足，我趕緊遠端登陸看了一下，c盤隻剩下128k，-_-.....
先臨時清了點東西，出了一百多m，恢複了系統運作，然後找是誰吃了硬碟空間：
不看不知道，一看吓一跳，原來是iis日志吃了近7個g的日志（vps上一般c盤就10g）
我打開日志，看都寫了啥日志。。一看吓傻了，都是壓力測試時産生的請求，一個日志近500m。
根據這個情況，我在想，對于小站點，不斷用多線程發送請求，造成日志快速增長，把對方空間給擠死，哈哈，好邪惡！！！
人生有兩出悲劇，一者執意尋死，一者無力求生，你全包了。
版權聲明：本文原創發表于部落格園，作者為路過秋天，原文連結：
http://www.cnblogs.com/cyq1162/archive/2013/03/26/2981082.html