次の方法で共有

パフォーマンスに関するその他の考慮事項

  • [アーティクル]

4 つの重要なパフォーマンス原則に加えて、外部要因による典型的なパフォーマンスの低下の理由が他にもいくつか考えられます。

クライアント ブラウザー、デバイス、場所の違いを考慮する

キャンバス アプリは、さまざまなネットワーク条件のさまざまなデバイス、ブラウザー、場所のユーザーが使用できます。 Power Apps クライアントを実行する場合、必ず最新の更新されたサポートされているブラウザーを使用してください。 大規模なデータを読み込む際に、iOS や Android などの異なるプラットフォームでは、アプリのパフォーマンスが異なる場合があります。 この変化は、プラットフォームごとにネットワーク要求の制限が異なるために発生します。 たとえば、同時に許可されるネットワーク リクエストの数は、プラットフォームによって異なります。 これらの違いは、大規模なデータセットのデータの読み込み時間に大きな影響を与える可能性があります。

オンプレミスのデータ ゲートウェイと環境の地理的な場所の違いを考慮する

ユーザーはグローバルにキャンバス アプリにアクセスできます。 ただし、ほとんどのエンド ユーザーの近くにデータ ソースを配置することをお勧めします。 たとえば、アプリが オンプレミス データ ゲートウェイにアクセスする場合、アプリに最も頻繁にアクセスするユーザーの近くにゲートウェイを配置するのが最善です。

サーバー側の一般的な問題

パフォーマンスの低下は、データのサーバー ソースの問題が原因である可能性があります。 これは、さまざまな理由で発生します。 監視ツールを使用して、データ呼び出しのタイミングを測定することで、特定の問題を評価できます。

データ ソースで考えられるボトルネックの問題

データ ソースには、ボトルネックの原因として考えられるものがたくさんあります。 通常、データ ソース内のいくつかのテーブルが、多くのクエリのアクティビティの中心となります。 次の場合、クエリが遅くなる可能性があります。

  • データ ソースが見つからないか、インデックスが正しくありません。
  • クエリはサーバー上の非常に大量のデータを結合しています。
  • クエリには StartsWith のようなインデックスを使用する代わりに、たとえば In 演算子を使用するテーブル SCAN が必要です。
  • データ ソースをホストしているバックエンド マシンのリソースが不足している。
  • バックエンド SQL インスタンスに、ブロッキング、デッドロック、またはリソース競合がある。
  • オンプレミス データ ゲートウェイが健全でない。
  • オンプレミス データ ゲートウェイをスケールアウトする必要があります。

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

特定のデータ ソース

Azure SQL Database

ビジネス要件に適した階層を選択することが重要です。 詳細については、Azure SQL Database のドキュメントを参照してください。 下位の階層にはいくつかの制限や制約があります。 パフォーマンスの観点から、CPU、I/O スループット、待機時間は重要です。 そのため、定期的に SQL データベースのパフォーマンスを確認し、リソース使用量がしきい値を超えていないかどうかを確認することをお勧めします。 たとえば、オンプレミスの SQL Server は通常、CPU 使用率のしきい値を約 75% に設定します。

SharePoint

SharePoint コネクタを使用すると、SharePoint リストのデータを使用してアプリを作成できます。 ここでは、SharePoint の一般的なパフォーマンスの問題と解決策をいくつか示します。

多すぎる動的な検索列を使用しない: SharePoint は、個人、グループ、計算などの動的な検索を含む、さまざまなデータ型をサポートしています。 リストに定義されている動的な列が多すぎる場合は、キャンバス アプリを実行しているクライアントにデータを返す前に、SharePoint 内でこれらの動的な列を操作するのに時間がかかります。 これを回避するには、SharePoint の動的な検索列を過度に使用しないでください。 たとえば、静的な列を使って、メールのエイリアスや人の名前などを管理します。

画像の列と添付ファイルを慎重に使用する: 画像のサイズや添付ファイルのサイズによっては、クライアントへの送信時のレスポンスが低下する場合があります。 リストを確認して、必要な列のみが定義されていることを確認します。 リスト内の列の数は、データ要求のパフォーマンスに影響します。 これは、一致したレコード、または定義されたデータ行の制限までのレコードは、アプリがすべての列を使用していない場合であっても、リストに定義されたすべての列が取得され、クライアントに送信されるためです。

大規模なリストの分割を考慮する: 数十万のレコードを含む大規模なリストがある場合は、リストをパーティション分割するか、カテゴリや日付と時刻などのパラメーターに基づいて複数のリストに分割することを検討してください。 たとえば、データを年単位や月単位でさまざまなリストに保存できます。 このような場合、ユーザーが時間帯を選択して、その範囲内のデータを取得できるよう設計することができます。

Dataverse

Microsoft Dataverse をデータ ソースとして使用する場合、データ要求は、Azure API Management を経由せずに、環境インスタンスに直接送信されます。 そのため、他のデータ ソースよりも高速になる傾向があります。 詳細については、Microsoft Dataverse への接続時のデータ コール フローを参照してください。

カスタム テーブル構成を確認する: Dataverse でカスタム テーブルが使用される場合、キャンバス アプリでレコードを表示するには、追加のセキュリティ設定が必要になる場合があります。 詳細については、Dataverse のセキュリティ概要、環境内のリソースに対するユーザー セキュリティの設定、セキュリティ ロールと権限を参照してください。

Excel

Excel コネクタにより、キャンバス アプリは Excel ファイル内のテーブルに接続できます。 ただし、このコネクタには他のデータ ソースと比べて制限があります。 たとえば、委任可能な機能が制限されているため、キャンバス アプリがテーブルからデータを読み込めるのは最大 2,000 レコードに制限されます。 2,000 を超えるレコードをロードするには、データを他のデータ ソースとして異なるデータ テーブルに分割します。

新しい Excel コネクタを使用する: 新しい Excel コネクタ - Excel Business Onlineを必ず使用してください。 これにより、マルチユーザー アクセスが可能になり、競合の問題がより適切に処理されます。

Excel の大規模なデータ リストから必要な列だけを使用する: データ テーブルの数を多く含む Excel ファイルや、複数の列に膨大な量のデータが格納されているデータ テーブルを使用すると、アプリの動作が遅くなる場合があります。 この問題の影響を受けないようにするには、Excel ファイルのデータ テーブルに必要な列だけを定義します。

データベースとしての Excel の制限に注意してください。 Excel はリレーショナル データベース システムではありません: アプリからの変更は、ユーザーが Excel ファイルのデータを直接変更するのと同じ方法で Excel が管理します。 アプリの読み込み数は多いが、更新操作が少ない場合は、パフォーマンスに影響しない場合があります。 ただし、アプリが大量のトランザクションを必要とする場合、アプリのパフォーマンスに悪影響を与える可能性があります。 トランザクション数に特定のしきい値はありません。 また、操作されるデータによっても異なります。 また、ネットワークのオーバーヘッドやユーザーのデバイスなど、その他のいくつかの側面もアプリのパフォーマンスに影響を与えます。

地理的な場所の違いを考慮する: データの地理的な場所と顧客の場所からの距離がパフォーマンスの問題になる可能性があります。 この問題は、モバイル クライアントの帯域幅が制限されている場合に大きくなる場合があります。