☰

Azure 應用程式服務上的 MySQL 非常慢，附有 PHP (Wordpress)

tag-icon • tag-icon php azure wordpress azure-web-apps
Azure 應用程式服務上的 MySQL 非常慢，附有 PHP (Wordpress)

我正在嘗試解決 Azure 應用程式服務與 Azure 資料庫連線速度非常慢的問題。

從廉價的 OVH 託管遷移 WordPress 後，我注意到 TTFB 非常長：從 300-400 毫秒增加到 1500-3000 毫秒。

我將問題範圍縮小到應用程式服務 - 資料庫連線問題。為了找出問題，我創建了乾淨的 WordPress 安裝。根據 P3 - 外掛效能分析器，乾淨的 WP 安裝會建立 38 個資料庫查詢。

使用 PHP/MySQL CPU 效能統計外掛程式我運行了 MySql Test：

  • Azure 應用程式服務：20-50 db 查詢/秒
  • 便宜的 OVH 託管：每秒 200 多個資料庫查詢

我認為如果 200 美元/月的 Azure 堆疊比 10 美元 OVH 慢大約 20 倍，那麼問題就非常明顯了（但是：我發現即使每秒約 40 db 查詢也會導致 TTFB 大約 300 毫秒，這是我的目標）。

為了解決這個問題，我嘗試了以下測試/更改：

  • 不同的應用程式服務計劃（從 dev 到 P2v3）
  • 不同的 Azure 資料庫伺服器（從最便宜到約 300 美元/月）
  • PHP 7.4 和 PHP 8.0
  • Apache 和 nginx（隨 php 7/8 變更自動提供）
  • Azure 資料庫單一且彈性伺服器
  • 適用於 MySQL 和 MariaDB 的 Azure 資料庫
  • 應用程式服務透過公用 IP 和 vnet 整合與資料庫連接
  • 將資料庫放置在完全相同的可用區中
  • ssl 和非 ssl 應用程式/資料庫連接
  • 資料庫重定向mysqlnd_azure
  • 嘗試連接持久性
  • 應用程式服務 docker 容器中的 WordPress

以上都不是性能發生任何重大變化。唯一“有效”的“修復”是啟用快取。如果命中緩存，TTFB 約為 100 毫秒（如預期）。

我還對 AWS Elastic Beanstalk/RDS 和 Google App Engine/CloudSQL 進行了基準測試，它們運行完美（開箱即用，TTFB 約為 250 毫秒）。連接到相同 Azure 資料庫的 Azure VM (PHP+ Apache) 運作正常（<300ms TTFB）。

我沒主意了。我缺什麼？需要明確的是：我並不是試圖實現個位數的反應時間或終極效能 - 對於乾淨的 WP 安裝來說 300 毫秒是可以接受的。

答案1

由於問題中沒有提到，所以需要注意一些事情。

  1. 確保 Web 應用程式和資料庫位於同一區域。這可能看起來很基本，但我以前見過。
  2. 使能夠永遠在線在 Azure 應用程式服務的設定中。 永遠在線：即使沒有流量，也能保持應用程式載入。當「始終開啟」未開啟（預設）時，應用程式將在 20 分鐘後卸載且沒有任何傳入請求。由於其預熱時間，卸載的應用程式可能會導致新請求出現高延遲。什麼時候永遠在線打開後，前端負載平衡器每五分鐘向應用程式根發送一次 GET 請求。連續 ping 會阻止應用程式被卸載。
  3. 審查應用服務最佳實踐。

答案2

我也有同樣的問題。 Azure 非常非常慢而且沒有任何作用？

PP_1，啟用快取是什麼意思？你是指像 WP Rocket 這樣的外掛嗎？

答案3

這裡有同樣的問題。我已經做了一些透過 web ssh 連接到容器實例的測試，我發現它需要 php載入插件需要 200-300 毫秒。 h所以我的最終結論是azure有php的問題。

我很好奇是否有人在沒有快取的情況下在 azure 上達到了不錯的效能（在 linux 上使用 php）。

我們最終使用啟動腳本配置了應用程序，該腳本重新配置 NGIX 以積極快取頁面，這對於我們的一些網站來說效果很好，但遠非理想。現在，我們的快取頁面的 TTFB 為 50 毫秒。

答案4

問題在於 Azure 應用程式服務使用儲存空間的方式。這就是為什麼插件需要很長時間才能加載的原因。

簡而言之，應用程式服務無法勝任託管 Wordpress！

相關內容