ER 構成で起こるトラブルシューティング パフォーマンスの問題

この記事では、電子申告 (ER) 構成 で起こるパフォーマンスの問題を検索して解決する方法について説明します。

通常、パフォーマンス調査は複数のステップで構成されます。

1. データ 収集します。
2. 収集したデータを分析します。
3. 分析結果に基づいて、ER 構成を使用して 変更する か、データをさらに収集することを決定します。

トラブルシューティング

実行時間の分析

実行時間は、同じ環境で実行されている他のタスクや、データを初めて呼び出したときにデータを使用するキャッシュなど、予測できない要因によって異なる場合があります。 そのため、実行と測定を数回繰り返す必要があります。

パフォーマンスの問題は、レポートで使用する ER 形式の構成が原因でない場合があります。 その場合は、ER 形式の構成を開くために使用する X++ コードが原因です。

1. アクション センター または イベント ログ で、レポートの実行時間を確認します。

2. レポートの実行時間とシナリオの合計実行時間を比較します。

3. レポートの実行時間が合計実行時間よりかなり短い場合は、レポートで処理されるデータ量を考慮してください。

   • レポートで処理されるデータが少量の場合、問題は構成の読み込み時間に関係する可能性があります。
   • レポートで処理されるデータが大量にある場合、問題は前処理の X++ に関係する可能性があります。 Trace Parser を使用してこのケースを分析します。

   その他のケースについては、次のセクションを参照してください。

4. 異なる量のデータを含む複数のテストを実行して、実行時間がデータ量にどう影響されているかを判断します。

Trace Parser トレースの分析

小規模な例を準備するか、またはレポート生成時に複数のトレースをランダムに収集します。

次に、Trace Parser で標準のボトムアップ分析を行い、次の質問に答えます。

• 時間消費に関して優れたメソッドは何ですか。
• これらのメソッドに必要な時間は、全体のどの時間ですか。

クエリに対して同じ質問に答えます。

メソッドの先頭に "ER" が付いている場合は、次のセクションに進みます。

アプリケーション スイートで作成されたメソッドまたはクエリが表示された場合は、汎用的な最適化 (インデックスの作成など) を検討してください。

呼び出し回数を分析します。 この回数が予想よりも大幅に多い場合は、対応する構成ノードをキャッシュすることを検討してください。

データベース呼び出しの分析

少量のデータを含む例を準備し、ER トレース を収集できるようにします 。

次に、ER モデル マッピング デザイナーでトレースを開き、ページの下部を確認します。 次の質問に答えます。

• 重複したクエリはありますか。 ある場合は、次のいずれかの修正を検討してください。

  • キャッシュを すると、1つのレコード内に複数の呼び出し親できます。
  • キャッシュされたパラメータ化された計算フィールドを使用 異なるレコード内に同じレコードへの呼び出しがある場合に使用します。
  • データベースから 数 のレコード 読み取る必要がある場合は、A、5つの異なるレコードのソースを使用します。

• クエリおよびフェッチされたレコードの数は、データの合計数と一致しますか。 たとえば、ドキュメントに明細行が 10 ある場合、レポートが 10 または 1,000 の明細行を抽出したと統計に表示されていますか。 フェッチされるレコードが多数ある場合は、次のいずれかの方法で修正を考慮してください。

  • 同じ 、 機能の代 場所 機能 を使用して、機能に関するデータ Microsoft SQL Server します。
  • キャッシュを使用して、同じデータをフェッチするのを防ぎます。
  • 収集したデータ機能を して、集計のために同じデータをフェッチしないようにします。

PerfView 追跡の分析

PerfView は経験豊富な開発者のためのツールです。 次の手順の詳細については、時計時刻調査の基本 を参照してください。

1. スレッド時間を使用して追跡を収集します。

2. runUnattended を使用するスタックのみを含めて、構成が実行されているスレッドのみをフィルター処理する必要があります。 (IncPats の入力ボックスに runUnattended を追加します。)

3. すべての CPU、ネットワーク、およびブロックされた時間を折りたたみます。

4. PerfView 用の ER プリセット を読み込みます。

5. ER>その他のプリセット を選択します。

6. 名前を確認します。

   • ほとんどの時間を消費するプラットフォーム コードが表示されます。

   • ダブルタップ (またはダブルクリック) し、呼び出し先 を上方向に移動して確認します。

     接頭語 "ERExpression" を持つクラスおよび式に関連する関数のクラスがある場合は、クラス名に基づいて関数名を変更でき、ER レポジトリを参照して属性を表示できます。

修正

• クエリが CPU 時間の大部分を消費する場合は、クエリの数を減らしてください。

  • 重複するクエリの場合は、ER を確認します。
  • フェッチされるレコード数を確認し、理論的にフェッチするデータの量を評価します。

• 使用している機能がほとんどの CPU 時間を消費する場合は、リソースを最も消費する構成で場所を探してください。

• データ収集機能が CPU 時間の大半を消費する場合、モデル マッピング側で SQL グループ別 に置き換えることを検討してください。

データ収集

環境によっては、使用可能なデータを収集する方法がいくつかあります。

• 合計実行時間を確認する。

  • アクション センターから
  • イベント ログから

• 実行をプロファイルする。

  • ER ツールを使用
  • Trace Parser を使用
  • PerfView を使用

運用環境でデータの収集

運用環境でのみ問題を再現できる場合があります。 次の方法でデータを収集できます。

• Trace Parser トレースを使用
• ER 実行 トレースを使用
• 合計実行時間を使用

開発環境でデータの収集

運用環境で使用できるツールの他に、開発環境で使用できるツールもあります。

• イベント ログ (Microsoft-Dynamics-ElectronicReporting)。 このログを使用すると、合計実行時間を確認できます。
• 一般的な .NETツール (PerfView など)。

また、開発環境では柔軟性が増すため、実験しやすくなります。 たとえば、レポートの一部をオフにすると実行時間への影響を確認できます。

ツール

アクション センターでの実行時間

ER では、アクション センターで構成の実行時間を表示できます。 このオプションは、対話型セッションで特定のユーザーと会社に対してのみ使用することができます。 この機能を使用するには、次の手順に従います。

1. 組織管理> 電子申告> コンフィギュレーションに移動します。
2. 構成ページ、アクション ウィンドウ、構成タブ、詳細設定グループで、ユーザー パラメーターを選択します。
3. ユーザー パラメーター ダイアログ ボックスで、ファイル生成時間の表示 オプションを はい に設定します。

イベント ログでの実行時間

1. Windows イベント ビューアーを開きます。
2. アプリケーションとサービス ログ で、Microsoft-Dynamics-ElectronicReporting/Operational を開きます。
3. EventID=2 の FormatMapingRun イベントを検索します。これらのイベントには、経過時間に関する情報が含まれます。

Trace Parser トレース

ER は X++ に実装されているので、一般的な X++ ツールを使用してパフォーマンスを分析できます。 詳細については、Trace Parser を使用したトレースの取得 を参照してください。

この方法にはいくつかの制限があります。 ER の一部が C# に実装されているため、表示できない詳細があります。 ただし、データの使用状況の詳細は表示できます。 また、長いレポートを実行すると、トレースのストレージ制限を超える可能性があります。

ER トレース

ER は独自のトレースを収集し、そのトレースには視覚化および分析ツールが含まれます。 詳細については、電子申告形式の実行をトレースしてパフォーマンスの問題をトラブルシューティング を参照してください。

PerfView

X++ と ER の両方が .NET プラットフォーム上に実装されているので、共通の .NET ツールを使用できます。 たとえば、無料の PerfView ツールを使用できます。

また、コマンド ラインからデータを収集することもできます。 たとえば、次の Windows PowerShell スクリプトは、マシンであらゆる形式の実行が停止されるまでの実行時間を収集します。

c:\programs\PerfView collect "e:\traces\$(date -format "ddMMyyyy_hhmm").etl" `
    -CircularMB:20000 -ThreadTime `
    -NoNGenRundown `
    -StopOnEtwEvent:Microsoft-Dynamics-ElectronicReporting/FormatMappingRun/Stop

この方法にはいくつかの制限があります。 マシンへの管理アクセス権が必要です。 また、難易度がかなり高いため経験豊富な開発者である必要があります。

変更の実行

キャッシュの使用

キャッシュによってデータの再フェッチに必要な時間が短縮されますが、メモリが必要です。 フェッチされたデータの量が大きくない場合は、キャッシュを使用します。 キャッシュの使用方法の詳細と例については、実行トレースの情報に基づいてモデル マッピングを改善する を参照してください。

フェッチされるデータの量の削減

実行時にフェッチするアプリケーション テーブルのレコードのフィールド数を制限することで、キャッシュのメモリ消費量を削減できます。 この場合、ER モデル マッピングで必要なアプリケーション テーブルのフィールド値だけをフェッチします。 そのテーブルの他のフィールドはフェッチされません。 したがって、フェッチされたレコードのキャッシュに必要なメモリの量が少なくなります。 詳細については、I実行時にフェッチされたテーブル フィール尾の数を削減することで ER ソリューションのパフォーマンスを改善する をご覧ください。

キャッシュされパラメーター化された計算済フィールドの使用

値を繰り返し検索する必要がある場合があります。 例には、アカウント名やアカウント番号が含まれます。 時間を節約するために、トップ レベルのパラメーターを含む計算済フィールドを作成し、そのフィールドをキャッシュに追加します。

この方法は、キャッシュされたデータのサイズが小さい場合にのみ使用することをお勧めします。 詳細については、パラメーター化された計算済みフィールド データ ソースを追加して ER のパフォーマンスを向上させる を参照してください。

結合データ ソースを作成する

結合 データ ソースを使用すると、接続されている複数のレコードを 1 つのクエリでフェッチすることができます。 接続されている各レコードをフェッチするために個別のクエリを使用する必要はありません。 たとえば、行が 1,000 あり、リレーションごとに各行の品目データをフェッチすると、1,001 クエリ (= 1,000 + 1) になります。 結合 データ ソースを使用する場合は、同じデータをフェッチするのに必要なクエリは 1 つのみです。 詳細については、ER モデル マッピングの結合データ ソースを使用して、複数のアプリケーション テーブルからデータを入手する を参照してください。

WHERE 関数の代わりに FILTER 関数を使用します

FILTER 関数は、SQL Server で条件を実行しますが、WHERE 関数は一覧からすべてのデータをフェッチし (一度に 1 つのレコード) 各レコードの条件を適用します。 たとえば、1,000 あるレコードの中からレコードを 1 つ選択するとします。 WHERE を使用すると、1,000 のレコードすべてがフェッチされます。 ただし、FILTER を使用すると、ちょうど 1 つのレコードがフェッチされます。 FILTER データベース側でインデックスを使用することはできません。

収集されたデータ機能または累積データ ソースの使用

コンフィギュレーションに、以前にレポート別にフェッチされたデータを集計する グループ化 コンポーネントがある場合、そのコンポーネントは、すべてのデータを再度フェッチします。 収集したデータ機能を使用すると、ER は最初のフェッチ時にデータを累積できるようになります。 詳細については、集計と合計を実行するのに必要な ER 構成形式 を参照してください。

X++ の構成の一部を再書き込みする

ER は、テーブルおよびクラスの呼び出しメソッド (拡張子を含む) をサポートします。 パフォーマンスを向上させるために、X++ でモデル マッピングの一部を再書き込みしてください。

ER は次のソースからデータを消費できます。

• クラス (オブジェクト および クラス データ ソース)
• テーブル (テーブル および テーブル レコード のデータ ソース)

ER アプリケーション プログラミング インターフェイス (API) は、呼び出しコードから計算済データを送信する方法も提供します。 アプリケーション スイートには、このアプローチの例が多数あります。