一般的なキャンバス アプリのパフォーマンスの問題と解決策
データ ソースのさまざまな配列を使用してキャンバス アプリを構築できます。 アプリの用途であるビジネス ニーズとシナリオに応じて、適切なデータ ソースとコネクタを選択します。 エンタープライズ アプリの場合、Microsoft Dataverse は、様々なパフォーマンス上の利点があるため、推奨されるデータ ソースです。 トランザクションが少ないアプリの場合は、環境内で利用可能な他のデータ ソースを使用できます。
アプリのパフォーマンスに関する考慮事項については、公開時にアプリを使用するユーザーの数を考慮してください; 作成、取得、更新、および削除 (CRUD) トランザクションの量; データのやり取りのタイプ; 地理的アクセス; ユーザーが持っているデバイスの種類。
この記事では、キャンバス アプリの動作が遅くなる原因となる、最も一般的なパフォーマンス問題とその解決方法について説明します。 この情報は、ビジネス プランや成長を念頭に置いて、アプリのパフォーマンスを向上させるのに役立ちます。
ここでは、使用しているコネクタを問わずに発生する一般的なパフォーマンスの問題について説明します。 この後のセクションでは、各コネクターに特有のパフォーマンス上の問題とその解決策について説明しています。
開始する前に、キャンバス アプリの実行フェーズとデータ呼び出しフロー について、理解していることを確認してください。 また、キャンバスアプリのパフォーマンス低下の原因 では、キャンバス アプリのデザインや更新の際に避けることのできる一般的な落とし穴について説明しています。
様々なプラットフォームで、大規模なデータ セットの読み込みに時間がかかる
大規模なデータを読み込む際に、iOS や Android などの異なるプラットフォームでは、アプリのパフォーマンスが異なる場合があります。 この変化は、プラットフォームごとにネットワーク要求の制限が異なるために発生します。 たとえば、同時に許可されるネットワーク リクエストの数は、プラットフォームによって異なる場合があります。 この違いは、大規模なデータ セットのデータの読み込み時間に大きな影響を与える可能性があります。
画面にすぐに表示する必要があるデータのみを読み込むことをお勧めします。 その他のデータについては、データのページ設定と キャッシュ を行います。 詳細情報 : キャンバス アプリのパフォーマンスを向上させるためのヒントとベスト プラクティス
取得された列が多すぎます
アプリに必要なカラムのみを選択することをお勧めします。 データソースからより多くの (またはすべての) 列を追加すると、その列のすべてのデータがダウンロードされます。 このアクションにより、ネットワークのオーバーヘッドコールの数が多くなるため、クライアント機器のメモリ使用量が多くなります。 この問題は、ネットワークの帯域幅が限られている、デバイスのメモリに制限がある、プロセッサが旧式である場合などに、モバイルデバイスを使用するユーザーにさらに影響を与えます。
たとえば、アプリのデータ ソースに Dataverse を使用する場合、明示的な列選択 機能が有効になっていることを確認してください。 この機能により、Power Apps は、アプリで使用される列のみに対してデータの取得を制限できます。
キャンバス アプリで明示的な列選択機能をオンにするには、設定 > 今後の機能 > プレビューにアクセスし、明示的な列の選択をオンに切り替えます。
サポートされていないブラウザーまたはレガシ ブラウザー
サポートされていないブラウザーまたはレガシ ブラウザーを使用しているユーザーは、パフォーマンスの問題が発生する可能性があります。 ユーザーがキャンバス アプリを実行するために サポートされているブラウザー のみを使用していることを確認してください。
地理的な距離のためパフォーマンスが遅い
環境の地理的な位置や、データ ソースとユーザーとの距離などがパフォーマンスに影響する場合があります。
ご利用の環境がユーザーの位置に近いことが理想的です。 Power Apps はコンテンツに Azure コンテンツ配信ネットワーク (CDN) を使用しますが、データ呼び出しは引き続きデータ ソースからデータを取得します。 データソースが別の場所にあると、アプリのパフォーマンスに悪影響を及ぼす可能性があります。
地理的な距離は、待機時間、スループットの低下、低帯域幅、パケット損失など、さまざまな形でパフォーマンスに影響を与えます。
許可リストが構成されていません
必要なサービス URL がブロックされていないこと、またはファイアウォールの許可リストに追加されていることを確認してください。 Power Apps に許可する必要のあるすべてのサービス URL の完全なリストについては、必要なサービス にアクセスしてください。
委任できない関数の使用と、委任できないクエリに対する不適切なデータ行数制限
委任可能な関数 は、データの処理をデータソースに委ねることで、クライアント側のオーバーヘッドを最小限に抑えます。 委任ができない場合は、委任できないクエリのデータ行数を制限することで、サーバーベースの接続から返される行数を最適に保つことができます。
委任できない関数の使用や、委任不可能なクエリに対する不適切な データ行の制限 は、データ転送に余分なオーバーヘッドの原因となります。 このオーバーヘッドにより、クライアント側で受信したデータが JS ヒープ に操作されます。 また、委任可能なアプリには必ず委任可能な関数を使用し、委任可可能なクエリには最適なデータ行数を使用してください。
OnStart イベントのチューニング必要
OnStart イベントは、アプリケーションの読み込み時に実行されます。 アプリの OnStart プロパティ の関数を使用して大量のデータを呼び出すと、アプリの読み込みが遅くなります。 他の画面で定義されたコントロールや値に大きく依存している画面は、画面のナビゲーションの遅延の影響を受けます。
次のセクションでは、これらの状況で発生する最も一般的な問題のいくつかについて説明します。
OnStart イベントでの呼び出し数が多いため、アプリの起動が遅くなる
企業では、中央データ ソースへの大量のデータ呼び出しにより、サーバーのボトルネックやリソースの競合が発生する可能性があります。
キャッシュ メカニズム を使用して、データの呼び出しを最適化します。 ひとつのアプリを多くのユーザーが使用すると、ユーザーごとに複数のデータ呼び出しがサーバーのエンドポイントに到達することになります。 これらのデータ通話は、ボトルネックやスロットリングが発生する原因となります。
スクリプトが重いため、OnStart イベントで待機時間
OnStart イベントでの重いスクリプトは、キャンバス アプリを設計する際の最も一般的な間違いのひとつです。 そのため、アプリの起動に必要なデータのみを取得する必要があります。
OnStart イベントで式を最適化します。 たとえば、代わりに一部の関数を OnVisible プロパティに移動します。 こうすることで、アプリを迅速に起動させ、アプリが開いている間に他の手順を進めることができます。
詳細情報 : OnStart プロパティを最適化する
ヒント
アプリの起動を簡素化し、アプリのパフォーマンスを向上させることができるため、App.StartScreen プロパティの使用をお勧めします。
クライアント側でのメモリ圧迫
ほとんどの場合、キャンバス アプリはモバイル デバイスで実行されるため、キャンバス アプリのメモリ消費量を確認することは重要です。 特定のデバイスでキャンバス アプリがクラッシュしたり、フリーズ (ハング) する原因として、ヒープでのメモリ例外が考えられます。
クライアント側で列の追加、結合、フィルター処理、並べ替え、グループ化などを実行する重いスクリプトが原因で、JavaScript (JS) のヒープが限界に達する場合があります。 ほとんどの場合、クライアントのヒープでメモリ不足の例外が発生すると、アプリのクラッシュや、ハングを引き起こす可能性があります。
Dataverse や SQL Server などのソースからデータを使用する場合、ビュー オブジェクトを使用して、結合、フィルター処理、グループ化や並べ替えがクライアント側ではなく、サーバー側で行うようにすることができます。 このアプローチにより、このようなアクションのスクリプト作成によるクライアントのオーバーヘッドを削減できます。
2,000 レコード以上のデータセットで JOIN や Group By などのクライアント負荷の高い操作がクライアント側で発生した場合、ヒープ内のオブジェクトが増加し、結果的にメモリ制限を超えることになります。
ほとんどのブラウザーの開発ツールで、メモリのプロファイルを作成できます。 ヒープ サイズ、ドキュメント、ノード、リスナーを視覚化します。 Microsoft Edge (Chromium) 開発ツールの概要 に記載されているように、ブラウザを使用してアプリのパフォーマンスをプロファイリングします。 JS ヒープのメモリしきい値を超えるシナリオを確認してください。 詳細情報 : メモリの問題を修正する
SQL Server コネクタを使用する際のパフォーマンスに関する考慮事項
SQL Server connector for Power Apps を使用してオンプレミスの SQL Server または Azure SQL Database に接続できます。 このセクションでは、このコネクタをキャンバスアプリに使用する際の一般的なパフォーマンス関連の問題と解決策について説明します。 詳細情報 : Power Apps から SQLServer に接続する、 Azure SQL データベースからキャンバス アプリを作成する
注意
このセクションでは、パフォーマンスに関する問題とその解決方法について SQL Server コネクタを参照していますが、推奨事項のほとんどは、データソースに—MySQL や PostgreSQL—などの他のデータベースタイプを使用する場合にも適用されます。
キャンバス アプリに SQL Server コネクタを使用する場合の一般的なパフォーマンスの問題と解決策を見てみましょう。
N+1 クエリ
サーバーへのリクエスト数が多すぎるギャラリーでは、N+1 クエリ問題が発生します。 N+1 query の問題は、ギャラリー コントロールを使用する際に最もよくに発生する問題のひとつです。
この問題を回避するには、SQL バックエンドでビューオブジェクトを使用するか、ユーザー インターフェースのシナリオを変更します。
インデックス シーク代替としてのテーブル スキャン
アプリで使用される関数がデータベースでクエリを実行し、その結果がインデックス シークではなくテーブル スキャンである場合、アプリケーションの速度が低下する可能性があります。 詳細: ヒント、Table SCAN、および Index SEEK
このような問題を解決するには、式で IN の代わりに StartsWith を使用します。 SQL データ ソースを使用する場合、 StartsWith 演算子はインデックス シークになります; ただし、IN 演算子は、インデックスまたはテーブル スキャンになります。
低速なクエリ
SQL データベースで低速なクエリとインデックスをプロファイルおよび調整できます たとえば、特定の列で降順 (DESC) の特定のデータを取得する式がある場合、その並べ替え列には降順のインデックスが必要です。 インデックス キーは、既定で昇順 (ASC) を作成します。
データ要求の URL アドレスを確認することもできます。 たとえば、次のデータ要求スニペット (部分的な OData 呼び出し) は、SQL に、列が 値 に一致する 500 件のレコードを返し、ID を降順で並べるよう要求します。
Items? \$filter=Column eq 'Value' & Orderby = ID desc & top 500
これは、同様の要求条件をカバーするインデックス要件を理解する際に役立ちます。 この例では、ID 列に降順のインデックスがあれば、クエリはより早く実行されます。
低速なクエリの実行プランを確認し、テーブルまたはインデックス スキャンが存在するかどうかを確認します。 実行プランでキー検索の過度なコストを監視します。
詳細:
データベース リソースの競合
データソースの —SQL データベース—に、プロセッサのボトルネック、I/O の競合、メモリの圧迫、tempDB の競合などのリソースの競合がないことを確認します。 また、ロック、待機、デッドロック、クエリのタイムアウトを確認します。
ヒント
潜在的なクエリ パフォーマンスの問題に関する分析情報、推奨される解決策、および特定された問題の自動修正に、自動調整 を使用します。
シック クライアントまたは過度なリクエスト
クライアント側でGroup By、Filter By、JOIN 操作を実行するアプリは、クライアント デバイスからのプロセッサとメモリ リソースを使用します。 データのサイズによっては、これらの操作がクライアント側でより多くのスクリプト作成に時間を要し、クライアント上の JSヒープ サイズが増大する可能性があります。 オンプレミスのデータソースの場合、ルックアップ データの各呼び出しがデータ ゲートウェイを経由してデータソースに伝わるため、この問題は大きくなります。
このような状況では、SQL データベースの ビュー オブジェクトを グループ別、フィルター、または JOIN 操作に使用します。 ビューでは、選択列を使用し、 NVARCHAR(MAX)、VARCHAR(MAX)、VARBINARY(MAX) などのビッグデータ タイプで不要なカラムを削除することができます。
ヒント
このアプローチは、N+1 クエリの問題 への対処にも役立ちます。
クライアントに転送されるデータ サイズ
既定では、キャンバス アプリは、使用可能なデータベース オブジェクトのテーブルやビューを使用してデータを表示します。 テーブルからすべての列を取得すると、特に NVARCHAR(MAX) などのビッグ データ型を使用している場合に、応答が遅くなる可能性があります。
大量のデータをクライアントに転送するには時間がかかります。 この転送により、この記事の前半で説明したように、クライアント側の JS ヒープに大量のデータがある場合、スクリプト時間が長くなります。
クライアントに転送されるデータのサイズを減らすには、アプリに必要な特定の列を持つビューを使用し、この記事の前半で説明したように明示的な列選択が有効になっていることを確認します。
オンプレミスの SQL Server に固有の考慮事項
オンプレミスのデータ ゲートウェイで SQL Server コネクタを使用するキャンバス アプリのパフォーマンスは、さまざまな形で影響を受ける可能性があります。 このセクションでは、オンプレミスのデータベース ソースの使用に固有の一般的なパフォーマンスの問題と解決策を示します。
正常でないオンプレミス データ ゲートウェイ
組織は、オンプレミス データ ゲートウェイに複数のノードを定義できます。 ひとつでも到達できないノードがある場合でも、不調なノードへのデータ リクエストは、許容できる時間内に結果が返ってこなかったり、しばらく待った後に 「unreachable」 というエラーメッセージが表示されたりします。
すべてのオンプレミスのデータ ゲートウェイ ノードが健全であり、ノードと SQL インスタンス間のネットワーク レイテンシーが最小となるように構成されていることを確認します。
オンプレミス データ ゲートウェイの場所
データ ゲートウェイでは、OData 要求を解釈するために、オンプレミスのデータ ソースへのネットワーク呼び出しが必要です。 たとえば、データ ゲートウェイは、OData 要求を SQL データ操作言語 (DML) ステートメントに変換するために、データ テーブルのスキーマを理解する必要があります。 データ ゲートウェイが別の場所に構成され、データ ゲートウェイと SQL インスタンス間のネットワーク待ち時間が大きい場合、余剰のオーバーヘッドが追加されます。
エンタープライズ環境で、大量のデータ要求が予想される場合は、スケーラブルなデータ ゲートウェイ クラスターを用意することをお勧めします。 データ ゲートウェイ ノードと SQL インスタンスの間に確立されている接続の数を確認します。
オンプレミスのデータ ゲートウェイまたは SQL インスタンスで同時接続を確認することにより、組織は、データ ゲートウェイをスケール アウトする必要がある時点と、ノードの数を決定できます。
データ ゲートウェイの拡張性
オンプレミス データ ゲートウェイから大量のデータにアクセスすることが予想される場合、オンプレミス データ ゲートウェイの1つのノードでさえ、このような大量のリクエストを処理する上でボトルネックになることがあります。
200 以下の同時接続を処理するには、オンプレミス データ ゲートウェイの 1 つのノードで十分な場合があります。 しかし、これらすべての同時接続がアクティブにクエリを実行している場合、他の要求は使用可能な接続を待つことになります。
データやリクエストの量に応じてオンプレミス データ ゲートウェイを確実にスケーリングする方法については、 オンプレミス データゲートウェイのパフォーマンスを監視、最適化する をご覧ください。
Azure SQL Database に固有の考慮事項
キャンバス アプリは、SQL Server コネクタを使用して Azure SQL Database に接続できます。 Azure SQL Database を使用する際のパフォーマンス問題の一般的な原因は、ビジネス要件に適していない層を選択していることに起因します。
Azure SQL Database は、さまざまなサービス層で利用でき、さまざまなビジネス要件に合わせてさまざまな機能を備えています。 階層の詳細については、Azure SQL Database のドキュメント に移動します。
大量のいデータリクエストがある場合、しきい値に達すると同時に、選択したティアのリソースが調整される可能性があります。 このような調整は、次の一連のクエリのパフォーマンスを低下させます。
Azure SQL Database のサービス層を確認してください。 下位の層にはいくつかの制限や制約があります。 パフォーマンスの観点から、CPU、I/O スループット、待機時間は重要です。 そのため、定期的に SQL データベースのパフォーマンスを確認し、リソース使用量がしきい値を超えていないかどうかを確認することをお勧めします。 たとえば、オンプレミスの SQL Server は通常、CPU 使用率のしきい値を約 75 % に設定します。
SharePoint コネクタを使用する際のパフォーマンスに関する考慮事項
SharePoint コネクタ を使用して、Microsoft Lists のデータを使用してアプリを作成します。 リスト ビューから直接キャンバス アプリを作成することもできます。 キャンバス アプリで SharePoint データ ソースを使用する場合の一般的なパフォーマンスの問題と解決策を見てみましょう。
動的な検索列が多すぎます
SharePoint は、個人、グループ、計算 などの動的なルックアップを含む、さまざまなデータ型をサポートしています。 リストに定義されている動的な列が多すぎる場合は、キャンバス アプリを実行しているクライアントにデータを返す前に、SharePoint 内でこれらの動的な列を操作するのに時間がかかります。
SharePoint の動的な検索列を過度に使用しないでください。 この過剰使用は、データの操作に対して SharePoint 側で回避可能で余剰なオーバーヘッドをもたらす可能性があります。 その代わり、静的な列を使って、メールのエイリアスや人の名前などを管理することができます。
画像の列と添付ファイル
画像のサイズや添付ファイルのサイズによっては、クライアントへの送信時のレスポンスが低下する場合があります。
リストを確認して、必要な列のみが定義されていることを確認します。 リスト内の列の数は、データ要求のパフォーマンスに影響します。 これは、一致したレコード、または定義されたデータ行の制限までのレコードは、アプリがすべての列を使用していない場合であっても、リストに定義されたすべての列が取得され、—クライアントに送信されるためです。
アプリが使用するカラムのみを照会するには、この記事の前半に記載している ように明示的なカラム選択機能を有効にします。
大規模なリスト
数十万のレコードを含む大規模なリストがある場合は、リストをパーティション分割するか、カテゴリや日付と時刻などのパラメーターに基づいてリストを複数のリストに分割することを検討してください。
たとえば、データを年単位や月単位でさまざまなリストに保存できます。 このような場合、ユーザーが時間帯を選択して、その範囲内のデータを取得できるよう設計することができます。
制御された環境内で、パフォーマンス ベンチマークは、Microsoft Lists または SharePoint に対する OData リクエストのパフォーマンスが、リスト内の列の数と取得される行の数に大きく関係していることを実証しています (委任できないクエリのデータ行の制限)。 列数を減らし、データ行の上限を低く設定すると、キャンバス アプリのパフォーマンスが向上します。
ただし、実際には、アプリは特定のビジネス要件を満たすように設計されています。 リスト内のデータ行の制限、または列数の削減は、迅速でも簡単でもない場合があります。 ただし、クライアント側で OData リクエストを監視し、委任できないクエリのデータ行数の制限や、リストの列数を調整することをお勧めします。
データ ソースとして Dataverse を使用する際のパフォーマンスに関する考慮事項
Microsoft Dataverse をデータ ソースとして使用する場合、データ リクエストは、Azure API Management を経由せずに、環境インスタンスに直接送信されます。 詳細情報: Microsoft Dataverse への接続時のデータ コール フロー
ヒント
Dataverse でカスタム テーブルがで使用される場合、キャンバス アプリでレコードを表示するには、追加のセキュリティ設定が必要になる場合があります。 詳細情報 : Dataverse のセキュリティ概要、 環境内のリソースに対するユーザーセキュリティの設定、セキュリティ ロールと権限
Dataverse に接続されたキャンバス アプリが、フィルター や JOIN などのクライアントに負荷のかかるスクリプトをサーバーサイドではなくクライアントサイドで実行すると、パフォーマンスが低下することがあります。
可能であれば Dataverse ビュー を使用します。 必要な結合またはフィルター基準を備えたビューは、テーブル全体を使用するオーバーヘッドを削減するのに役立ちます。 たとえば、テーブルを結合してそのデータをフィルタリングする必要がある場合は、結合することで ビューを定義し、必要な列のみを定義できます。 続いて、アプリでこのビューを使用して、クライアント側ではなくサーバー側で結合/フィルターのオーバーヘッドを作成します。 この方法は、余分な操作を削減するだけでなく、データ転送も削減します。 フィルターと並べ替え条件の編集については、フィルター条件の編集 に移動します。
Excel コネクタを使用する際のパフォーマンスに関する考慮事項
Excel コネクタ は、キャンバス アプリから Excel ファイル内のテーブルのデータへの接続を提供します。 たとえば、delegable 関数が制限されており、キャンバス—アプリがテーブルからデータを読み込むことができるのは—2,000 レコードまでに限られるなど、他のデータソースに比べて制限があります。 2,000 を超えるレコードをロードするには、データを他のデータ ソースとして異なるデータ テーブルに分割します。
ここでは、キャンバス アプリのデータ ソースに Excel を使用する際のよくあるパフォーマンス上の問題と、その解決方法についてご紹介します。
データ テーブルが多すぎてデータ サイズが大きい
データ テーブルの数を多く含む Excel ファイルや、複数の列に膨大な量のデータが格納されているデータテーブルを使用すると、アプリの動作が遅くなる場合があります。 Excel ファイルは、リレーショナル データベースでも、委任可能な機能を提供するデータ ソースでもありません。 Power Apps は、まず定義されたデータ テーブルからデータを読み込む必要があり、次に Filter、Sort、JOIN、Group By、Search などの関数を使用します。
行や列の多いデータテーブルが多いと、各データテーブルを JS ヒープ内で操作する必要があるため、アプリのパフォーマンスやクライアント サイドのオーバーヘッドに影響が出ます。 この影響により、アプリはクライアント側のメモリをより多く消費します。
この問題の影響を受けないようにするには、Excel ファイルのデータ テーブルに必要な列だけを定義します。
大量のトランザクション
Excel はリレーショナル データベース システムではありません。 アプリからの変更は、ユーザーが Excel ファイルのデータを変更するのと同じ方法で Excel が管理します。 アプリの読み込み数は多いが、CRUD 操作が少ない場合は、パフォーマンスに影響しない場合があります。 ただし、アプリが大量のトランザクションを行うと、アプリのパフォーマンスに悪影響を与える可能性があります。
トランザクションの数は、操作されるデータにも依存するため、特定のしきい値はありません。 また、ネットワークのオーバーヘッドやユーザーのデバイスなど、その他のいくつかの側面もアプリのパフォーマンスに影響を与えます。
読み取り専用データがある場合は、データ ソースから読み込む代わりに、そのようなデータをアプリにローカルにインポートできます。 エンタープライズ アプリの場合、代わりに Dataverse、SQL Server、または SharePoint のようなデータ ソースを使用します。
ファイル サイズ
さまざまな クラウド ストレージ オプションから選択でき、Excel ファイルのストレージ—容量を変更あるいは—構成することができます。 しかし、すべてのテーブルが定義された1つの大きな Excel ファイルがある場合、アプリがファイルをダウンロードしてデータを読み込み、クライアント側でロードする際に、余分なオーバーヘッドが発生します。
ひとつの大きなファイルを使用する代わりに、最小限のデータ テーブルでデータを複数の Excel ファイルに分割します。 この場合、必要な場合にのみ各ファイルに接続します。 こうすることで、データ テーブルからのデータの読み込みが断片的に行われ、多くのテーブルや大きなデータセットに起因するオーバーヘッドを軽減することができます。
ファイルの場所
データソースの地理的な位置や、クライアントの場所 からの距離によって、アプリのパフォーマンスのボトルネックになったり、ネットワークの遅延が発生したりすることになります。 この影響は、モバイル クライアントの接続に向けた帯域幅が制限されている場合に大きくなります。
ファイルがすぐにダウンロードできるように、ユーザー (グローバルに展開している場合はほとんどのユーザー) の近くにファイルを配置することをお勧めします。
次の手順
キャンバス アプリのパフォーマンスを向上させるためのヒントとベストプラクティス
関連項目
キャンバス アプリの実行フェーズとデータの呼び出しフローを理解する
キャンバス アプリのパフォーマンス低下の一般的な原因
Power Apps の一般的な問題と解決方法
Power Apps のスタートアップに関する問題のトラブルシューティング
注意
ドキュメントの言語設定についてお聞かせください。 簡単な調査を行います。 (この調査は英語です)
この調査には約 7 分かかります。 個人データは収集されません (プライバシー ステートメント)。
フィードバック
近日公開予定: 2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub イシューを段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、以下を参照してください: https://aka.ms/ContentUserFeedback。
フィードバックの送信と表示