什麼可能導致 IIS 中的請求被阻止？
我在兩台幾乎相同的伺服器上使用帶有 MySQL 和 PHP 的 Windows Server 2016 上的 IIS。我最近注意到我的兩台伺服器之一的速度變慢了，但只有當我的站點嘗試同時執行多個腳本實例時才會發生這種情況。他們似乎被困在了彼此身上。
一個完美的例子是我的搜尋頁面。當使用者鍵入搜尋查詢時，每次按鍵（在第二個字母之後）只要自上次按鍵後至少有 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 中執行我在此搜尋中執行的選擇語句，它們在兩台伺服器上的性能同樣出色。僅在我的網路應用程序中遇到此問題。
為了以防萬一，我暫時撤消了我對 IIS 所做的兩個更改以上傳更大的文件，但這似乎沒有什麼區別。
我還下載並安裝了 LeanSentry，它每天會警告我一兩次我的網站已經看到被阻止的請求，我認為這正是我在這裡看到的，但不幸的是，LeanSentry 只能查明 ASP 問題的根源頁面，而不是 PHP。所以它本質上只是對我確認存在問題，但除此之外它無法幫助我。
其他症狀
如果我同時打開多個報告，我會看到類似的問題。如果我允許一個報告在打開下一個報告之前完成載入，它們都會快速載入，但如果我強制我的應用程序一次打開多個報告，它們都會卡住。
什麼可能導致這個瓶頸問題？
事實證明，HTML 渲染導致了掛起。當我的搜尋結果很長時，瀏覽器需要很長時間才能呈現所有 HTML，並且在這樣做時它無法處理下一個請求。
我通過將搜尋結果限制為 50 行解決了這個問題，因此現在 HTML 幾乎立即呈現並且可以執行下一個請求。因此，阻止請求的不是 IIS，而是瀏覽器。
我認為不是它的 IIS 伺服器在這裡有問題，你搜尋的每一件事都在你的程式碼中請求一個新的呼叫，它看起來像你的 PHP 腳本中的東西需要很長時間。
每次你發送一個新請求時，你只是阻塞了一個新的 PHP 瞬間，當 PHP 用完瞬間它就會崩潰。
很難知道您在搜尋 PHP 文件中在做什麼，但我認為您正在呼叫某個 SQL 伺服器或其他東西進行搜尋。您可以嘗試在程式碼中註釋搜尋查詢並進行相同的測試嗎？
現在我只是猜測我能做到的最好的，它聽起來就像你在 SQL 數據庫中使用正則表達式或類似的函式，當你有很多行時，它的呼叫速度非常慢，這就是它掛起很多的原因。
但我只是想這麼晚我才知道我告訴你做的測試結果。