>>>

本來不想轉這篇檔案， 現在中有公司還用iss6

這幾天給一遊戲論壇做優化，論壇版本為：DISCUZ 7.2

環境是：Windows server 2003 SP2+IIS+PHP+MYSQL
硬體：雙路CPU8核+8G記憶體+2X147G SAS硬碟
負載：3000人實時線上

本想勸其改用linux架構，被其拒絕，理由是他不懂Linux，現在想來，你懂windows，出了問題你還是解決不來，那還不如用Linux，一般不會出問題呢

言歸正傳吧

論壇情況如下：

1，CPU不穩定，經常100%，時而又0%
2，訪問非常緩慢
3，時而報錯：No input file specified
4，時而報錯：service unavailable

OK，下面我們一一分析並解決吧

先解決報錯問題
第一步：檢查硬體，看看硬體是否有問題，這裡由於出現了“No input file specified” 和 “service unavailable”這兩個錯誤
所以先檢查磁碟是否有問題，注意，在複製大檔案或大量碎檔案的時候會導致service unavailable這個問題
這裡我檢查後發現他伺服器硬體並沒有問題，排除之；

第二步：判斷網路是否良好，做運維的慣例，第一二補都是檢查硬體和網路，把基礎問題排除掉，我檢查發現他伺服器網路並沒有問題

第三部：OK，我們來看看作業系統是否有問題，看作業系統日誌，看系統是否有問題，看到系統有很多錯誤日子和警告日誌，我一一檢視，發現並沒有系統元件或核心級別的錯誤，排除系統錯誤，系統是沒有問題的

第四步：檢視是否受到攻擊，是否中毒，是否修改了配置
經過檢視並未發現有被攻擊的可能

第六步：重啟服務，大家不要輕視重啟，windows重啟能解決非常多非常多的問題哦，我考慮了一下，因為伺服器以前是好的，現在且一直沒人有誤操作，甚至沒有人登入過，而且並沒有被攻擊，人數也不是高峰期，和平常一樣的線上人生，為什麼就突然這樣了呢，得出終結就是：系統自動安裝了補丁，沒有重啟剩下！！！！

OK，那就重啟吧，爭取得到對方同意後，重啟了，OK，問題解決了不少，報錯少了很多很多，但論壇依然慢

第五步：上面都排除了，下面就重點來看看效能優化了

首先看看日誌，發現經常報如下幾個錯誤：

1，應用程式池：
為應用程式池 'bbs' 提供服務的程序關閉時間超過了限制。程序 ID 是 '9564'。

2，HTTP錯誤：
事件 ID ( 54 )的描述(在資源( HTTP )中)無法找到。本地計算機可能沒有必要的註冊資訊或訊息 DLL 檔案來從遠端計算機顯示訊息。您可能可以使用 /AUXSOURCE= 標識來檢索詞描述；檢視幫助和支援以瞭解詳細資訊。下列資訊是事件的一部分: \Device\Http\AppPool.
3，程序間通訊錯誤：
為應用程式池 'bbs' 提供服務的程序在與 World Wide Web Publishing 服務通訊時遇到致命錯誤。程序 ID 為 '7684'。資料欄位包含錯誤號。

嗯，主要是這三種錯誤，我們來來分析一下
WIMP(windows+iis+php+mysql)架構工作原理：
1，客戶端請求IIS
2，IIS處理靜態頁面，動態頁面通過php5isapi.dll動態擴充套件交給PHP處理
3，PHP解析並且通過mysq擴充套件函式(php.ini裡面開啟)請求MYSQL查詢和插入等操作
4，mysq程序處理PHP發過來的處理請求

整個過程就這樣，那麼好，最前面的問題我們來歸個類：

No input file specified：這個問題世界上是PHP 404 什麼是PHP 404呢，也就是靜態頁面不報這樣的錯誤，說明和IIS配置，路徑等都沒有問題（注意哦，No input file specified這個錯誤也有可能是許可權，路徑等的錯誤哦，我這裡不是），那麼就是PHP檔案無法被執行了，這說明是第三個環節出問題了，也就是PHP處理出現了問題，或者是IIS的動態擴展出現問題

service unavailable：這個基本就是IIS的處理問題，或者硬體資源達到極限，導致IIS無法處理下一個請求

下面來我做了如下操作

1，註釋掉 php.ini裡面的doc_root項
2，註釋掉 php.ini裡面的cgi.fix_pathinfo=0項
3，設定系統盤下c:\tmp許可權新增everyone完全控制


重啟PHP：也就是重啟IIS了
OK：No input file specified問題解決了，不再報這個錯誤了

下面來解決速度慢和service unavailable問題
先利用windows 2003的效能計數器看看IIS當前連線數(IIS併發連線)

開啟--管理工具--效能---效能日誌和警報能看到如下圖：

然後按照下列圖示來操作

OK，能看到IIS實時併發連線數了

這裡是2000-3000的連線，可以看出併發不是很大，對於8核心+8G記憶體的伺服器來說，處理這些連線是沒有問題的！！！！

我們再來看看負載情況吧：

可以看出，負載比較低的，但IIS就是慢，看來只能優化應用程式池了，我做了如下優化，如圖

去掉請求佇列限制

最大工作程序改為了2

重啟IIS，OK問題終於解決了，速度終於飆起來了

轉載於:https://my.oschina.net/notbad/blog/278371