%20%E3%82%92%E4%BD%BF%E7%94%A8%E3%81%97%E3%81%9F%20Azure%20App%20Service%20%E3%81%A7%E3%81%AE%E9%9D%9E%E5%B8%B8%E3%81%AB%E9%81%85%E3%81%84%20MySQL.png)
Azure App Services から Azure データベースへの接続が非常に遅いという問題を解決しようとしています。
安価な OVH ホスティングから Wordpress を移行した後、TTFB が非常に長いことに気付きました。300 ~ 400 ミリ秒から 1500 ~ 3000 ミリ秒に増加しました。
問題をアプリ サービス - データベース接続の問題に絞り込みました。問題を正確に特定するために、クリーンな WordPress インストールを作成しました。P3 - プラグイン パフォーマンス プロファイラーによると、クリーンな WP インストールでは 38 個のデータベース クエリが作成されます。
PHP/MySQL CPU パフォーマンス統計プラグインを使用して、MySql テストを実行しました。
- Azure App Service: 20~50 db クエリ/秒
- 安価な OVH ホスティング: 200 以上の db クエリ / 秒
月額 200 ドルの Azure Stack が 10 ドルの OVH より約 20 倍遅い場合、問題はかなり明白だと思います (ただし、1 秒あたり約 40 db クエリでも TTFB が約 300 ミリ秒になる可能性があることがわかっており、これが私の目標です)。
この問題を解決するために、次のテスト/変更を試しました。
- さまざまな App Service プラン (dev から P2v3 まで)
- さまざまな Azure データベース サーバー (最も安価なものから月額 300 ドル程度まで)
- PHP 7.4 および PHP 8.0
- Apache および nginx (php 7/8 の変更により自動的に付属)
- Azure データベース シングル サーバーとフレキシブル サーバー
- Azure データベース (MySQL および MariaDB 用)
- パブリック IP および VNET 統合を介したデータベース接続へのアプリ サービス
- データベースをまったく同じアベイラビリティゾーンに配置する
- SSL および非 SSL アプリ/データベース接続
- データベースリダイレクトmysqlnd_azure
- 接続の持続を試みた
- App Service Docker コンテナ内の Wordpress
上記のどれでもないパフォーマンスに大きな変化はありませんでした。唯一「機能する」修正方法は、キャッシュを有効にすることです。キャッシュがヒットした場合、TTFB は予想どおり約 100 ミリ秒になります。
また、AWS Elastic Beanstalk/RDS と Google App Engine/CloudSQL のベンチマークも行いましたが、これらは完璧に動作しました (すぐに使用できる状態で約 250 ミリ秒の TTFB)。同じ Azure データベースに接続された Azure VM (PHP+ Apache) も正常に動作しました (<300 ミリ秒の TTFB)。
アイデアが尽きました。何が足りないのでしょうか? 誤解のないよう明確に言うと、私は 1 桁の応答時間や究極のパフォーマンスを実現しようとしているわけではありません。クリーンな WP インストールでは 300 ミリ秒で十分です。
答え1
質問には記載されていなかったので、注目すべき点がいくつかあります。
- Web アプリとデータベースが同じリージョンにあることを確認します。これは基本的なことのように思えますが、以前にも見たことがあります。
- 有効にする常にオンAzure App Service の設定で。 常にオン: トラフィックがない場合でもアプリをロードしたままにします。常時オンがオフの場合(デフォルト)、アプリは20分間受信リクエストがないとアンロードされます。アンロードされたアプリはウォームアップ時間があるため、新しいリクエストの待ち時間が長くなる可能性があります。常にオンがオンになっている場合、フロントエンド ロード バランサーは 5 分ごとにアプリケーション ルートに GET 要求を送信します。継続的な ping により、アプリがアンロードされるのを防ぎます。
- レビューアプリ サービスのベスト プラクティス。
答え2
私も同じ問題を抱えています。Azure は非常に遅く、何も機能していません。
PP_1、キャッシュを有効にするというのはどういう意味ですか? WP Rocket のようなプラグインのことですか?
答え3
私も同じ問題を抱えています。Web SSH経由でコンテナインスタンスに接続するテストをいくつか行いましたが、phpが必要なことがわかりました。プラグインを読み込むのに200~300ms. h したがって、最終的な結論としては、Azure には PHP に関する問題があるということです。
キャッシュなしで Azure で適切なパフォーマンスを達成した人がいるかどうか (Linux 上の PHP を使用) 非常に興味があります。
最終的に、NGIX を再構成してページを積極的にキャッシュする起動スクリプトを使用してアプリを構成することになりました。これは一部のサイトではうまく機能しますが、理想にはほど遠いものです。現在、キャッシュされたページの TTFB は 50 ミリ秒です。
答え4
問題は、Azure App Services がストレージを使用する方法にあります。これが、プラグインの読み込みに時間がかかる理由です。
つまり、App Services は Wordpress をホストするのに適していないのです。