在AWS上突然變慢的PHP應用程序

我在AWS上運行一箇舊的PHP（7.1）/ NGINX（1.10.2）應用程序。該應用程序在AWS上運行超過幾個月。自2天以來，我們遇到了高延遲問題。但它不會影響整個頁面。只有「密集型」PHP流程似乎在交付內容方面存在問題。在AWS上突然變慢的PHP應用程序

現在我查了很多其他相關的主題，但沒有任何東西指向正確的方向。

首先：等待時間與網絡無關，因爲當從服務器向本地主機發送請求時，也會收到這些等待時間。它似乎也與數據庫無關（該網站可以在< 3ms內連接到RDS DB，而DB CPU〜20％，內存自由> 2GB看起來不錯）。連接到數據庫並運行網絡服務器進行的一些查詢也表現良好。

網絡服務器本身不佔用太多的硬件資源（CPU 10-25％和內存空閒〜2GB）。此服務器上未安裝任何cronjobs /計劃任務。服務器上仍有超過50％的iNodes可用。網關正在檢索/傳輸8-25MB /秒。我們根本不監視任何類型的DoS。

我已經檢查並試圖調整PHP FPM設置（memory_limit，進程管理，子進程等）。這裏沒有什麼幫助。取消/激活OPCache確實沒有影響。

即使當我使用先前安裝的AMI並啓動新服務器時，也會再次發生相同的延遲問題。在多個可用區域中運行應用程序時也是如此。

要查看PHP花費的時間，我使用了blackfire.io，實際上它告訴我它大部分時間都用在了mysql交互上（這並不奇怪，因爲應用程序發送大量連接等的髒查詢。和它唯一的性能昂貴的東西在這裏..）。我還爲代碼本身添加了一些調試輸出。它通常在不到6秒內完成（這可悲的是我們從搜索中知道的正常平均值）。

根據目標羣體的等待時間平均在3-8秒之間，但我們也發現很多請求超時（30-60秒）的延遲。

在這一點上，我甚至不確定要在這裏提供什麼。我不想在這裏粘貼每個相關的配置等。所以請告訴我你需要什麼幫助：/

php-fpm/nginx日誌不會記錄任何與此問題有關的內容。與syslog一樣。唯一可以找到的是Timed out waiting for reply from 91.189.89.199:123 (ntp.ubuntu.com)，但即使date仍然同步.. PHP FPM慢日誌（超時設置爲5秒）也是空的。 ELB訪問日誌只監視高「backend_processing_time」。

Nginx實際上將請求路由到S3存儲區，除了一個S3掛載之外，我們沒有任何大量臨時文件或服務器上的其他東西。

發送到互聯網的請求按預期執行。 DNS似乎也不是問題（像平常一樣可以在互聯網上訪問數據庫和其他服務）。

有沒有人有想法可能會導致這些延遲問題？還應該調查哪些/ ？我非常感謝每一個幫助或問題，這些都可以讓我指出正確的方向。
最好的問候。

來源

2017-10-19 Tim

你使用T2 EC2實例嗎？ –

是的，通常很小，但我隨機也嘗試了一種媒介。 – Tim

您需要設置一些基本的操作系統監控，以關注CPU，內存和IO等事情，以便您可以瞭解服務器上正在發生的事情。如果你對性能的唯一可見性是「應用程序很慢」，那麼你將會有一段非常艱難的時間來確定問題實際上是什麼。 – Sammitch

你自己說的：

它告訴我，它花費大部分時間在MySQL交互（如應用程序發送了很多骯髒的查詢了很多聯接等，以及其這並不奇怪這裏唯一性能昂貴的東西..）。

這是你的應用程序。這會導致你的「管道」堵塞，所以有些人會經歷30-60等待。現在我還要檢查現在是否超時的任何file_get_contents，因爲這是突然的。

另外，我有一個問題是這樣before on serverfault，我特別想指出的my comment：

我並不爲這家公司工作了，他們在去 - 出於法律原因。但！當我離開時，我們的30秒負載站點降至3秒。我們的linode CPU出現故障。該解決方案完全是 - 緩存。我們框架的初始化過程在性能方面是非常昂貴的，而且內部框架沒有內置緩存。我只能說CACHE - 對象緩存，頁面緩存，使用清漆！這將解決你的問題（但你仍然會有一個糟糕的框架，當你無法緩存，你會傷心..你必須修復性能不佳的代碼）。

我希望這可以幫助你。哦也this comment too：

當你去看醫生，他告訴你採取一定吃藥 - 因爲他知道你不會聽「停止飲用蘇打水和吃快餐」的語句 - 這就是爲什麼有對我來說沒有很好的答案 - 因爲事實是，沒有設置或快速修復真正應用 - 只有我們必須大幅度改變我們的網絡應用程序本身的可悲事實。

來源

2017-10-19 22:53:42 amurrell

感謝您關於file_get_contents的提示我會研究這一點。當然，它顯然可能是應用程序。但是在過去3天內沒有任何變化（沒有流量增加，沒有數據庫中的索引變化等）。所以如果它從3-8秒下降到30或甚至60，我會非常驚訝，因爲它是一個糟糕的遺產應用程序.. – Tim

一旦我們因共享平臺鏈接上的file_get_contents而發生該問題。當然，我們在它前面有一個@符號。只是一個想法。另一個是 - 你是否被抓取？比你習慣的更重用法（什麼語句！）可能會觸發設計不佳的應用程序阻塞。 – amurrell

試着弄清楚這30-60秒是否確切，可能與實際的超時配置一致。並根據什麼網址/請求發生。 – amurrell

機器人的組合，來自雲服務器的一些請求我們搜索（幾個月以來），RDS Cpu信用和平均真正太多的SQL查詢的一些陌生人請求引起了這種現象。結果發現，t2中型實例的Cloudwatch指標顯示了2個核心（t2.medium的基準性能+有時更高的值30-80％）的CPU利用率平均值（20％），並且這會持續不斷地殺死所有cpu信用你失去了他們全部，然後很難獲得新的學分（例如在夜間）。

來源

2017-11-15 22:28:16 Tim

在AWS上突然變慢的PHP應用程序

回答

相關問題