我在 Windows Server 2016 上使用 IIS，在兩台幾乎相同的伺服器上使用 MySQL 和 PHP。我最近注意到兩台伺服器之一的速度變慢，但只有當我的網站嘗試同時執行腳本的多個實例時才會發生這種情況。他們似乎互相卡住了。
一個完美的例子是我的搜尋頁面。當使用者輸入搜尋查詢時，每次按鍵（在第二個字母之後），只要自上次按鍵以來至少有 200 毫秒的延遲，就會執行搜尋。因此，如果您打字速度快，它最後只會進行一次搜索，但對於打字速度較慢的人（按鍵之間等待時間超過 200 毫秒的人），這將觸發對搜索結果的多次調用。請參閱此螢幕截圖。
伺服器壞了
請注意所有待處理的請求，在此螢幕截圖中，第一個請求剛剛在 19.08 秒完成。顯然太長了。當它們全部完成時，它們都已經超過 15 秒來傳回一個簡單的結果集。
伺服器壞了
請記住，這些查詢在 MySQL Workbench 中執行時只需要幾分之一秒，在我的其他伺服器上執行時也不會遇到此問題。在這個螢幕截圖（來自良好的伺服器）中看到完全相同的搜尋在四分之一秒內返回。
良好的伺服器
在我看來，（在壞伺服器上）它們由於某種原因無法同時執行，因為如果我只執行一次搜索（通過快速鍵入以觸發一次搜索），它會很快返回，但如果我像這樣執行多次，他們都會像塞車一樣陷入困境。什麼可能導致這種情況？
下一個螢幕截圖顯示瞭如果我在壞伺服器上僅觸發一次搜尋的結果。正如你所看到的，它恢復得非常快。所以問題只出現在同時執行多個相同腳本時。
伺服器壞了
我最近確實對壞伺服器做了一些更改，但據我所知，我所做的唯一更改是允許更大的檔案上傳。
- 在 PHP 中我增加了 post_max_size = 500M
- 在 PHP 中我增加了 upload_max_filesize = 500M
- 在 IIS 中，我將 UploadReadAheadSize 增加到 49152000
- 在 IIS 中，我將允許的最大內容長度增加到 300000000
我可能對此伺服器進行了其他我不記得的更改。
臨時修復
我可以透過允許搜尋時按鍵之間更長的延遲來緩解這個問題，我已經這樣做了，將其增加到800 毫秒，這樣即使打字速度慢的人也不會看到這個問題，但這只是一個創可貼解決方案，並不能解決這個問題。
我嘗試過的
到目前為止，我已經確認我的 IIS 配置、MySQL 配置 (my.ini) 和 PHP 配置 (php.ini) 在兩台伺服器上的各個方面都是相同的（至少在我看來是顯而易見的） 。我還確認，如果我在 MySQL Workbench 中執行我在此搜尋中運行的 select 語句，它們在兩台伺服器上的表現同樣出色。僅在我的網頁應用程式中遇到此問題。
為了以防萬一，我暫時撤消了對 IIS 進行的兩項更改以上傳較大的文件，但這似乎沒有什麼區別。
我還下載並安裝了LeanSentry，它每天警告我一兩次我的網站已看到被阻止的請求，我認為這正是我在這裡看到的，但不幸的是LeanSentry 只能查明ASP 問題的根源頁面，而不是 PHP。所以它本質上只是向我確認有問題，但除此之外它無法幫助我。
其他症狀
如果我同時開啟多個報告，我會遇到類似的問題。如果我允許一份報告在打開下一份報告之前完成加載，它們都會快速加載，但如果我強制我的應用程式一次打開多個報告，它們都會被卡住。
是什麼導致了這個瓶頸問題？
答案1
我認為不是 IIS 伺服器有問題，您搜尋的每件事都在程式碼中請求新的調用，並且它看起來像是 PHP 腳本中的某些內容，需要很長時間。
每次發送新請求時，您都會阻塞一個新的 PHP 瞬間，而當 PHP 耗盡瞬間時，它就會崩潰。
很難知道您在搜尋 PHP 檔案中正在做什麼，但我認為您正在呼叫某些 SQL 伺服器或其他內容來進行搜尋。您可以嘗試在程式碼中註解掉搜尋查詢並進行相同的測試嗎？
現在我只是盡我所能猜測，聽起來就像您在 SQL 資料庫中使用正規表示式或類似函數一樣，當您有很多行時，呼叫速度非常慢，這就是它經常掛起的原因。
但我再次猜測，這麼晚了我才知道我告訴你做的測試的結果。
答案2
事實證明 HTML 渲染導致了掛起。當我的搜尋結果很長時，瀏覽器需要很長時間才能呈現所有 HTML，並且在執行此操作時無法處理下一個請求。
我透過將搜尋結果限制為 50 行解決了這個問題，因此現在 HTML 幾乎可以立即呈現，並且可以執行下一個請求。所以阻止請求的不是 IIS，而是瀏覽器。