パフォーマンスの最適化

完了

アプリのパフォーマンスを最適化する方法を知るため、まずアプリの起動時に何が起きるのかについて説明します。 次に、パフォーマンス低下のよくある原因について説明します。

アプリの実行フェーズとデータ呼び出しフロー

ユーザーがアプリとの対話を開始する前でも、アプリで最初に発生するいくつかの実行フェーズがあります。 その後、データ ソースによって異なるデータ呼び出しフローがアプリにより実行されます。

キャンバス アプリの実行フェーズ

キャンバス アプリでは、ユーザーにインターフェイスを表示する前に次の実行フェーズが発生します。

  1. ユーザーを認証する: この実行フェーズでは、初めてのユーザーに、アプリの接続用の資格情報を使ったサインインが求められます。 組織のセキュリティ ポリシーによっては、同じユーザーがアプリを再度開いたときに再度求められることがあります。
  2. メタデータを取得する: アプリが実行される Power Apps プラットフォームのバージョン、およびアプリがデータを取得する必要のあるソースなどのメタデータが取得されます。
  3. アプリケーションを初期化する: アプリの OnStart プロパティで指定されたタスクが実行されます。
  4. 画面をレンダリングする: 最初の画面で表現されるコントロールやデータなど、アプリの最初の画面がレンダリングされます。 同様に、アプリによって同じプロセスが実行され、ユーザーが開く後続の画面がレンダリングされます。

キャンバス アプリにおけるデータ呼び出しフロー

キャンバス アプリからのデータ呼び出しでは、OData プロトコルを使ってデータが送受信されます。 多くの場合、データ呼び出しはアプリから Azure API Management へ、API Management からデータ ソースへ移動し、逆の順序でアプリに戻る必要があります。 さらに、オンプレミスのデータ ソース (SQL Server など) がある場合、呼び出しはオンプレミスのデータ ゲートウェイも通る必要があります。

これらの呼び出しフローすべてによって、パフォーマンス上の考慮事項や潜在的な最適化の機会が生じる可能性があります。 ただし、アプリがデータ ソースとして Microsoft Dataverse を使用する場合、データ呼び出しには大きな違いがあります。 データ呼び出しが Dataverse ソースに移動すると、OData 要求は Azure API Management、コネクタ、またはデータ ゲートウェイを経由せずに Dataverse に直接移動します。 言い換えると、Dataverse を使用するとゲートの数が少なくなります。

キャンバス アプリのパフォーマンス低下のよくある原因

実行フェーズとデータ呼び出しフローの基本について理解できたので、次にキャンバス アプリのパフォーマンス低下のよくある原因について説明します。

アプリの設計

アプリの設計方法は数多くあるため、アプリの設計は広範囲に及びます。ただし、以下の側面はアプリのパフォーマンスに確実に影響を与えます。

  • クライアントに負荷のかかるアプリ: 最初に大規模なデータ セットをデータ コレクションにまとめ、JSON、Sort、AddColumns、GroupBy のようなクライアントに負荷のかかる操作に対して、複数の画面でデータを使用します。
  • アプリの OnStart に長い数式がある: 画面で不要なデータ呼び出しを多くトリガーする可能性があり、それらのデータ呼び出しが大規模なデータ レコードを返します。

アプリのパフォーマンス低下として考えられる原因がないかアプリの設計を確認するには、Monitor を使ってアプリを監視します。 時間がかかっているデータ呼び出しはどれかと、アプリでそのような動作をトリガーしているデータ呼び出しの数を確認します。

さらに、クライアントとサーバーの間でワークロードのバランスをとり、可能であればワークロードをサーバーに委任することをお勧めします。 クライアントのメモリ消費の観点では、クライアント アプリを軽量にすることが重要です。

データ ソースのボトルネック

データ ソースのボトルネックとして考えられる原因は数多くあります。 しかし、最もよくある原因は、多数のトランザクション クエリまたは非トランザクション クエリが異なるユーザーから同じテーブルまたはレコードに向けられると、データ ソースのテーブルが活動の中心になるという点です。

次の場合、OData 呼び出しの速度が低下する可能性があります。

  • データ ソースをホストしているバック エンド コンピューターのリソースが不足している。
  • バックエンド SQL インスタンスに、ブロック、デッドロック、またはリソースの競合がある。
  • オンプレミスのデータ ゲートウェイが異常である。

これらの問題が発生した場合、アプリのパフォーマンス低下を避けるため、バック エンド データ ソースを調整してください。

クライアント ブラウザー、デバイス、場所

キャンバス アプリは、ネットワークの条件が異なるさまざまなデバイス、ブラウザー、場所で使用できます。 更新された最新のサポートされているブラウザーを使用するようユーザーを促してください。

オンプレミスのデータ ゲートウェイおよび環境の地理的位置

ユーザーは、キャンバス アプリに世界中からアクセスできます。 ただし、最も大規模なユーザー ベースの近くにデータ ソースを配置することをお勧めします。 たとえば、アプリがオンプレミスのデータ ソースにアクセスする場合、データ ゲートウェイとデータ ソース間の余分なオーバーヘッドを最小限に抑えるため、オンプレミスのデータ ゲートウェイをデータ ソースの近くに配置してください。

バック エンドにおける大量の要求の一時的な調整

キャンバス アプリの設計方法によっては、短期間で多数のデータ呼び出しが生成される可能性があります。 データ呼び出しがコネクタの調整の制限を超えると、アプリが一時的な調整の対象となることがあります。 したがって、多くの観点から、適切なデータ ソースとコネクタを選択することが重要であり、コネクタ固有の制限について理解することが重要です。 発生する可能性がある制限について詳しくは、コネクタに関するドキュメントを確認ください。

公開されたアプリのデバッグ設定が有効になっている

公開されたアプリのデバッグ設定を有効にすると、アプリの実行が遅くなります。 公開されたアプリをデバッグするときにソース式を表示する必要がなくなったと判断した場合、この設定を無効にした状態でアプリを再公開できます。

要約すると、ユーザーが実行フェーズおよびデータ呼び出しフローでアプリの使用を開始したときにどうなるかについて説明しました。 さらに、アプリのパフォーマンス低下のよくある原因もいくつか説明しました。 このユニットでは詳しく説明しませんが、キャンバス アプリのパフォーマンスを高めるための実用的なヒントとベスト プラクティスPower Apps における最適化されたパフォーマンスに関する考慮事項について学習することができます。