サブネットワークスケーラビリティ分析
サブネットワークスケーラビリティ分析とは？
Utility Networkのサブネットワークスケーラビリティ分析について話す前に、サブネットワークとは何か、スケーラビリティ分析とは何かの定義を確認しましょう：
サブネットワーク：
ユーティリティネットワークでは、サブネットワークは、すべての参加するフィーチャが同じコントローラーへの接続性を持つティア内のデータのパーティションまたはトポロジックな部分集合です。サブネットワークはしばしばトレースに使用され、接続性が利用可能かどうかを判断します。
スケーラビリティ分析：
スケーラビリティ分析は、Utility Network展開が複数のリクエストを同時に実行できる能力（例：updateSubnetworkおよびexportSubnetwork）を判断するためのものです。これは通常、時間支配的なビジネス目標が達成可能かどうかを理解するために行われます。例えば、特定の展開が4時間以内に5,000のサブネットワークをエクスポートできるかどうか？
この質問への答えは、テストして検証するまで不明です。
展開のスケーラビリティは、関心のある操作の最適なパフォーマンスを維持しながら、一度にどれだけの同時実行が可能かに結びついています。この記事では、テスト（記事に含まれる）を通じて同時実行を適用する方法について説明します。
注意：サブネットワークの詳細については、以下をご覧ください： Utility Networkにおけるサブネットワークのライフサイクル
私たちのUtility Networkの目的と目標
- サブネットワークリストの更新またはエクスポート作業を自動化
- パフォーマンスタイムをキャプチャ
- 全体タスク
- 個々の操作（例：特定のサブネットワーク更新時間）
- 要件を満たすように構成可能なソリューション
なぜUpdate/Export Subnetwork分析を行うのか？
- 典型的な目的と時間制約はビジネス要件です
- 各サブネットワークで二つの機能を実行
- 更新 (updateSubnetwork)
- 編集後およびネットワークトポロジ検証が呼び出された後、またはネットワークトポロジ有効化が実施された後によく実行されます
- エクスポート (exportSubnetwork)
- サブネットワーク情報をファイルに抽出し、そのファイルは停電管理など外部システムで使用されます
- システムからサブネットワークをエクスポートする前に、それが最新（更新済み）である必要があります
両方とも重要なユーティリティネットワーク機能です。GIS管理者や開発者として、これらの操作がどのようにスケールするか理解することが重要です。サブネットワークリスト処理時間の理解が主な分析です。
さらに進めて、時間やシステムリソースを最適化するソリューションを探求できます。これらの課題には、多数のサブネットワークを更新またはエクスポートするタスクを達成するための類似したアプローチがあります。
- ビジネス目標への洞察獲得
- エクスポートするサブネットワークは使用されるオプションによって計算時間が長くなることがあります
- そのようなオプションはビジネス要件である場合があります
パフォーマンスとスケーラビリティはアーキテクチャに影響します
テスト結果と調査から
展開構成はビジネスニーズを満たすために変更が必要になる場合があります
サブネットワークスケーラビリティ分析をどのように達成するか？
サブネットワークリスト
最初のステップはUtility Networkデータセットからサブネットワークリストを抽出することです。
これは様々な方法で行うことができます：
ArcGIS Pro
ArcPyスクリプト
SQL選択文
SQL例：
UtilityNetworkジオデータベースに接続
このObjectIdは動的で変わる可能性があります
- Type GUIDは一定です
-- サブネットワークテーブル用Utility Network ObjectId検索
SELECT OBJECTID FROM sde.GDB_ITEMS WHERE type='{37672BD2-B9F3-48C1-89B5-8C43BBBB6D57}'
例として、このデータベースでは446が返されました
このObjectId値は次のクエリで使用されます
サブネットワークリストをエクスポート
-- サブネットワークリストエクスポート
SELECT
T1.SUBNETWORKCONTROLLERNAME, T1.SUBNETWORKNAME, T1.ISDIRTY,
T1.ISDELETED, T1.TIERNAME, T1.DOMAINNETWORKNAME, T1.GDB_FROM_DATE
FROM
elec.UN_446_SUBNETWORKS T1
INNER JOIN (SELECT SUBNETWORKNAME, MAX(GDB_FROM_DATE) AS MaxDate
FROM
elec.UN_446_SUBNETWORKS
GROUP BY SUBNETWORKNAME) T2
ON T1.SUBNETWORKNAME = T2.SUBNETWORKNAME
AND T1.GDB_FROM_DATE = T2.MaxDate
出力結果をファイル（csvまたはtsv）に保存
一部のSubnetworkControllerNamesにはカンマ（","）が含まれる場合があり、その場合カンマ区切りよりタブ区切りファイルが適切です
この記事で使用したUtility Networkデータセットの場合、データ行がタブで区切られたとき、結果として得られるサブネットワークリストは以下のようになります。
注意：現在のネットワーク状態にはクリーンおよびダーティなサブネットワークが含まれていると想定されています。サブネットワークがダーティになる理由はこの記事の範囲外です。
注意：選択して抽出するサブネットワークにはいくつかのビジネス要因があります。このクエリは開始点として役立ちます。
Apache JMeter
他の記事でも述べたように、Apache JMeter は無料のテストツールです。ArcGIS Enterprise の REST エンドポイントを多くの機能でテストするために最適です：
多くのテストツールがありますが、JMeter は ArcGIS Enterprise の Utility Network サービス呼び出しで updateSubnetwork と exportSubnetwork リクエストを行うために使用されます。
Utility Network データセット -- Naperville Electric
Naperville Electric データ、ArcGIS Pro から見た様子：
Update Subnetwork
Apache JMeter テストプランフォルダーのファイルシステムビュー
<\/span><\/P>JMeterの外では、Test Planは単独のjmxファイルです。ほかのCommunity Articlesで述べたように、作業しているプロジェクトのフォルダ構造を作成することが推奨されます。これは特に異なる多くのテストを行っている場合に管理に役立ちます。上記のフォルダでは、サブネットワークのリストとテスト結果はUpdateSubnetworkディレクトリ内に保持でき、他のテスト実行データと混同されにくくなります。<\/P>Update Subnetwork Test Plan<\/H2>この記事で使用されたApache JMeter Test Planをダウンロードするには、次を参照してください: UpdateSubnetwork1.zip<\/A><\/STRONG> <\/LI>Apache JMeterでTest Planを開くと次のように見えるはずです:<\/SPAN>環境に合わせてUser Defined Variablesを調整する<\/LI><\/UL><\/LI><\/UL>
<\/span><\/P>
Test Planの主要コンポーネント<\/H2>UpdateSubnetwork Test Planを展開すると、次の要素が見えます:<\/P>User Defined Variables上記リスト、テストを環境に合わせて簡単に調整するために使用<\/LI><\/UL><\/LI>Aggregate Reportテストのデバッグおよびテスト後分析に使用<\/LI><\/UL><\/LI>Thread Groupテストのスレッド同時実行数またはscalability<\/STRONG><\/U>を定義<\/LI>テスト作成中はデフォルト値（例：1テストスレッド）を使用することが推奨される<\/LI><\/UL><\/LI>GenerateTokenArcGIS Enterpriseからトークンを取得前述の資格情報を使用<\/LI><\/UL>テスト中はトークンを保持<\/LI><\/UL><\/LI>While Controller Syncビジネスロジックで呼び出しがsynchronous<\/STRONG>であるべき場合に使用<\/LI>サブネットワークリストをループ処理<\/LI><\/UL><\/LI>CSV Data Set Configテスト対象のサブネットワークリストとリンクCSVまたはTSVデータテキストファイル<\/LI><\/UL><\/LI><\/UL><\/LI>If ControllerGroovyを使ったテストのロジック分岐<\/LI>サブネットワークがdirtyの場合（IsDirty=TrueまたはIsDirty=1）に分岐をたどる<\/LI><\/UL><\/LI>USN Request (${SUBNETWORKNAME})作業の大部分を実行するリクエストを発行するテスト要素<\/LI>データファイルソースから${SUBNETWORKNAME}にサブネットワーク名が設定される<\/LI><\/UL><\/LI>While Controller Asyncビジネスロジックで呼び出しがasynchronous<\/STRONG>であるべき場合に使用非常に長時間実行されるupdateSubnetworkリクエストに理想的<\/LI><\/UL>サブネットワークリストをループ処理<\/LI>利用方法:While Controller Asyncを右クリックしてEnable<\/STRONG>を選択<\/LI>While Controller Syncを右クリックしてDisable<\/STRONG>を選択<\/LI>
<\/span>注意: Thread Groupの値はUpdate Subnetworkテストのscalabilityプロファイルを決定します。「Users」の値が大きいほど、テストが到達する最大同時実行数が高くなります。「Rampup」を増やすと、その期間（秒単位）で同時実行数が徐々に増加します。<\/strong>GenerateTokenについて詳しく見る
GenerateTokenリクエストはテストの重要な部分です。テストの早い段階で発生し、Utility Networkサービスは認証を必要とする可能性が高いです。
Generate Tokenリクエスト
<\/span>
トークンのキャプチャ
トークン要求は作業の半分です。もう半分はそれをキャプチャして変数として保存し、JMeterがテスト実行中にアクセスできるようにすることです。これはJMeterのRegular Expression Extractor要素で行われます。<\/span>
<\/span>
注意: 正規表現の仕組みはこの記事の範囲外ですが、本質的にはレスポンス内の特定文字列シグネチャを探し、それが見つかればagstokenというJMeter変数に格納します。<\/strong>
Update Subnetwork Test Planデータファイル-- サブネットワークリスト
CSV Data Set Config要素は非常に重要な役割を果たしそれによってサブネットワークデータリストとテストが結びついています。<\/span>
<\/span>
注意: 一部のUtility NetworkデータセットにはSubnetworkControllerName内にカンマ文字（例：","）が含まれる場合があります。この場合、サブネットワークリストはカンマ区切り値ではなくタブ区切り値として保存することが有利です。<\/strong>
注意: タブ区切り値ファイルが使用される場合でも、JMeterはサブネットワークリストのヘッダー行がカンマ区切りであることを期待します。<\/STRONG>
If Controller Logic
利便性のため、IsDirtyフィールドが1の場合のみリストからサブネットワークを更新するロジックが追加されました。Groovyがこのタスクをテスト内で実現しています。
Apache GroovyはJavaベースのスクリプト言語であり、標準的なJMeterテスト要素では難しい可能性がある強力な機能とプログラム的サポートを提供します。
Update Subnetwork HTTP Request
This test element in the Test Plan is the responsible for
updateSubnetwork
web calls in the test.
This component issues the request and JMeter evaluates the response coming back from ArcGIS Enterprise through the REST endpoint.
Test Execution
Graphic User Interface (GUI) execution
Ideal for test authoring and debugging
Play and Stop buttons
コマンドライン実行
公式なテスト実行に最適
より効率的なメモリ利用
特にAggregate Reportなどのリスナーが実行時に無効化されている場合
Play (consoleRun.bat) と Stop (Control-C)
consoleRun.bat経由でテストが実行されると、結果フォルダ内にa results.jtl file will be generated in the results folder
注意: 常に推奨されます 負荷テストの開始時間と期間を組織の適切な担当者と調整してください。これにより、ユーザーやオンプレミスのArcGIS Enterprise Siteを使用する必要がある他の同僚への影響を最小限に抑えることができます。さらに、他の活動や使用によるシステムノイズがテスト結果を「汚染」するのを防ぐのに役立ちます。
注意: いくつかの理由から、 ArcGIS Onlineが提供するサービスの負荷テストは絶対に行わないことを強く推奨します。
分析 -- レポートと評価
集計レポート要素（テストデバッグ）
この分析から、UpdateSubnetwork_Sync トランザクションと操作全体に関する重要なパフォーマンス情報を示すいくつかの主要な統計を簡単に確認できます。
おおよその合計時間の見積もりとして、1つのテストスレッドの同時実行で、サンプル数に平均値を掛けるだけです。例えば：「# Samples * Average」= 合計テスト実行時間 (ms)
「公式」のテスト実行の場合は、ツリーから集計レポートリスナーを無効にすること（右クリックして「無効化」を選択）を推奨し、テスト作成、デバッグ、およびテスト後処理のみで使用してください。
注意: テスト後処理では、GUIで無効になっていても集計レポートはテスト結果ファイルの参照、選択、読み込みに使用できます。
結果ファイル
コマンドラインスクリプトから実行すると、JMeterは出力の一部として結果ファイルを生成します。 結果ファイル（*.jtlファイル）は、生のリクエスト情報をテキスト形式で含みます。
このファイルにはすべてのサブネットワークとそれぞれの応答時間が一覧表示されています。一般的なエディタで開いて閲覧することは簡単ですが、この形式で分析を行うことは推奨されません。
集計レポート要素（テスト後分析）
集計レポート要素に戻ってテスト後分析を行いましょう。JMeter GUIから[参照]ボタンをクリックしてjtl結果ファイルを見つけ、「開く」を選択して読み込みます。
読み込まれると、jtlファイルはJMeterによって処理され、集計レポートセクションに統計レポートが生成されます。
集計レポート要素はインタラクティブなので、「最大値」ヘッダー欄をクリックしてリストを簡単に再ソートし、最も時間がかかっているサブネットワークを見つけることができます。UpdateSubnetwork_Sync トランザクションは依然としてリストされており、サービスレベルアグリーメント（SLA）から特定のパフォーマンス要件が満たされているか理解するために重要です。
注意: このデータセット内のサブネットワーク数は少ないです。本番データセットからのテスト結果ではより多くのサンプルがあります。
さらなる分析へ
結果ファイルはカンマ区切り値なので、スプレッドシートで簡単に開くことができます。
最小限の書式設定で結果データを表示したものです。
これは良いですが、もっと良くできるでしょうか？
トランザクションパフォーマンスのチャート化は明確さを向上させます。
注意: 全体的な数値だけが必要な場合は、個々のサブネットワークリクエスト（例：responseMessage = OK のフィールド）をフィルターしてください。
Export Subnetwork
Apache JMeter – テストプランフォルダのファイルシステムビュー
Export Subnetwork テストプラン
- この記事で使用されたApache JMeter テストプランをダウンロードするには: ExportSubnetwork1.zip
- Apache JMeterでテストプランを開くと次のようになります:User Defined Variables を環境に合わせて調整してください
注意: Thread Group の値を設定して Export Subnetwork テストのスケーラビリティプロファイルを決定します。「Users」の値が大きいほど、そのテストが到達する最大同時実行数が高くなります。「Rampup」を増やすことで、その期間（秒単位）にわたって同時実行数が徐々に増加し、最大値に達します。
Export Subnetwork HTTP リクエスト
このテストプラン内の要素は、test内でexportSubnetwork webコールを担当しています。
このコンポーネントはリクエストを発行し、JMeterはRESTエンドポイント経由でArcGIS Enterpriseから返される応答を評価します。
注意: この Export Subnetwork テストプランはデータファイル内のすべてのサブネットワークを書き出すよう設計されています。
高度な JMeter
Export Subnetwork 出力サイズ取得
exportSubnetwork リクエストは ArcGIS Server 上にファイルを生成します。この出力ファイル（一般的にはjsonまたはpbf形式）は他システムへインポート可能です。このアイテムのディスク上のサイズは変動しますが、有用なテストメタデータとして取得すると良いでしょう。
Request 要素で直接出力サイズを取得する方法も簡単ですが非常に非効率的です。しかし、このタスクは前述した Groovy 言語を活用し、高速に重いファイルシステム計算を実行する機会となります。
exportSubnetwork リクエスト後には二つの JSR223 Sampler の形で追加リクエストがあります:
- CalculateStatistics SN:${SUBNETWORKNAME}
- SN:${SUBNETWORKNAME} Size:${outputFileSizeKB}KB
最初のサンプルには Groovy ロジックが含まれており、export 出力ファイルを読み取り JMeter 変数へ格納します。
<\/span><\/P>Groovyロジックの詳細な解析:<\/P>\/\/ 変数といくつかの動的アーティファクトを取得してexportSubnetwork出力のファイルシステムパスを組み立てる
\/\/ exportSubnetwork出力のファイルシステムをディスク上で調査する
String outputUrl = vars.getObject("outputUrl"); \/\/ 前のリクエスト(exportSubnetwork)から取得
String outputFormat = vars.getObject("outputFormat"); \/\/ ユーザー定義変数
String subnetworkName = vars.getObject("SUBNETWORKNAME"); \/\/ CSVからのテストプラン変数
String serverName = vars.getObject("serverHostname"); \/\/ ユーザー定義変数
String folderServiceName = vars.getObject("serviceName"); \/\/ ユーザー定義変数
File srvc = new File(folderServiceName);
String folderName = srvc.getParent(); \/\/ サービスからフォルダ名を分離
String serviceName = srvc.getName(); \/\/ サービス名を分離
String outputName = org.apache.commons.io.FilenameUtils.getBaseName(outputUrl); \/\/ exportSubnetwork出力からファイル名を分離
outputNamewExt = outputName + "." + outputFormat; \/\/ ファイル拡張子を再付加
\/\/ 出力が存在すべきファイルシステムパスを作成; arcgisoutputディレクトリはJMeterを実行するユーザーに共有されていると仮定
\/\/ serverName変数がArcGIS Serverマシンでない場合は "\\\\MyServer.domain.org\\arcgisoutput\\" を使用
String cifsPath = "\\\\" + serverName + "\\arcgisoutput\\" + folderName + "\\" + serviceName + "_MapServer\\" + outputNamewExt;
File file = new File(cifsPath);
long cifsFileSize=file.length(); \/\/ exportSubnetwork出力のサイズを取得
double oneKilobyte=1024.0
double cifsFileSizeKB=(cifsFileSize\/oneKilobyte);
double cifsFileSizeKBRound=cifsFileSizeKB.round(2); \/\/ ユーザーフレンドリーなフォーマット済みファイルサイズ
log.info("folderServiceName: " + folderServiceName);
log.info("outputUrl: " + outputUrl);
log.info("cifsPath: " + cifsPath);
log.info("cifs file.exists: " + file.exists().toString());
log.info("serverName: " + serverName + " subnetworkName: \"" + subnetworkName + "\" size: " + cifsFileSizeKBRound + " KB outputName: " + outputNamewExt); \/\/ 情報をJMeterログに書き込む
vars.putObject("outputFileSizeKB",cifsFileSizeKBRound);<\/code><\/pre>2番目のSampleは単にキャプチャされたファイルサイズをテスト内のJSR223 Sampler要素のNameプロパティにリストします。この値はjtl結果ファイル内のリクエスト名として報告され、さらなる分析に使用できます。<\/P>例えば:<\/P>
<\/span><\/H2>非同期ジョブから個別サブネットワーク応答時間の取得<\/SPAN><\/H3>非同期実行スタイル<\/SPAN><\/H4>テストのデフォルト実行スタイルは同期です。これはシンプルでわかりやすいです。リクエストを発行し、応答を待つだけです。リクエストごとの応答時間が10分未満と予想される場合に理想的なアプローチです。 <\/SPAN><\/P>10分より長く実行されるリクエストには、非同期が推奨されます。ただし、非同期テストにはより多くの動作部分があります:<\/SPAN><\/P>ジョブが送信される<\/SPAN><\/LI>ジョブステータスがループ内で定期的にポーリングされる<\/SPAN>ループが複数ある<\/SPAN><\/LI><\/UL><\/LI>完了すると、そのジョブの出力場所がキャプチャされる<\/SPAN><\/LI><\/UL>これら各ステップはテスト内の独自のリクエストであり、それぞれ結果ファイルに応答時間がキャプチャされます。JMeterはこの合計時間をExportSubnetwork Asyncというトランザクション名で報告します（これは機能全体の便利な統計情報を提供するため素晴らしい）が、各個別サブネットワークとそれぞれの応答時間を簡単にリンクしません。<\/SPAN><\/P>
<\/span><\/P>再びGroovyが助けに来る<\/SPAN><\/H4>各サブネットワーク操作の単一応答時間は、非同期ループの開始と終了でタイマーを設定することでGroovyで計算できます。Groovyは単純に差分を計算し、テストに時間を返します（サイズ計算と同様）。<\/SPAN><\/P>
<\/span><\/P>Groovyロジックの詳細な解析:<\/P>\/\/ 変数といくつかの動的アーティファクトを取得してexportSubnetwork出力のファイルシステムパスを組み立てる
\/\/ exportSubnetwork出力のファイルシステムをディスク上で調査する
String outputUrl = vars.getObject("outputUrl"); \/\/ 前のリクエスト(exportSubnetwork)から取得
String outputFormat = vars.getObject("outputFormat"); \/\/ ユーザー定義変数
String subnetworkName = vars.getObject("SUBNETWORKNAME"); \/\/ CSVからのテストプラン変数
String serverName = vars.getObject("serverHostname"); \/\/ ユーザー定義変数
String folderServiceName = vars.getObject("serviceName"); \/\/ ユーザー定義変数
String startEpoch = vars.getObject("StartEpoch"); \/\/ While Controller Async内からのテストプラン変数
String stopEpoch = vars.getObject("StopEpoch"); \/\/ While Controller Async内からのテストプラン変数
File srvc = new File(folderServiceName);
String folderName = srvc.getParent(); \/\/ サービスからフォルダ名を分離
String serviceName = srvc.getName(); \/\/ サービス名を分離
String outputName = org.apache.commons.io.FilenameUtils.getBaseName(outputUrl); \/\/ exportSubnetwork出力からファイル名を分離
outputNamewExt = outputName + "." + outputFormat; \/\/ ファイル拡張子を再付加
\/\/ 出力が存在すべきファイルシステムパスを作成; arcgisoutputディレクトリはJMeterを実行するユーザーに共有されていると仮定
\/\/ serverName変数がArcGIS Serverマシンでない場合は "\\\\MyServer.domain.org\\arcgisoutput\\" を使用
String cifsPath = "\\\\" + serverName + "\\arcgisoutput\\" + folderName + "\\" + serviceName + "_MapServer\\" + outputNamewExt;
File file = new File(cifsPath);
long cifsFileSize=file.length(); \/\ Get size of exportSubnetwork output
long startEpochLong = Long.parseLong(startEpoch);
long stopEpochLong = Long.parseLong(stopEpoch);
long responseTimeMS = stopEpochLong-startEpochLong; \/\ 非同期exportSubnetworkのみ前回リクエストの***推定応答時間値***を計算
double oneKilobyte=1024.0
double cifsFileSizeKB=(cifsFileSize \/ oneKilobyte);
double cifsFileSizeKBRound=cifsFileSizeKB.round(2); \/\ ユーザーフレンドリーなフォーマット済みファイルサイズ
double responseTimeSec = ((responseTimeMS\/1000).round(2)); \/\ ミリ秒単位推定応答時間を秒に変換
log.info("folderServiceName: " + folderServiceName);
log.info("outputUrl: " + outputUrl);
log.info("cifsPath: " + cifsPath);
log.info("cifs file.exists: " + file.exists().toString());
log.info("serverName: " + serverName + " subnetworkName: \"" + subnetworkName + "\" size: " + cifsFileSizeKBRound + " KB responseTimeEstimate: " + responseTimeSec + " 秒 outputName: " + outputNamewExt); \/\ 情報をJMeterログに書き込む
vars.putObject("outputFileSizeKB",cifsFileSizeKBRound); \/\ 後で使用するため計算値を変数に格納
vars.putObject("responseTimeSec",responseTimeSec); \/\ 後で使用するため計算値を変数に格納<\/>code>追加戦略<\/>/SPAN>時間対リソース<\/>/SPAN>時間制約例<\/>/STRONG >一定期間内にタスク完了が必要 (例：4時間で5,000サブネットワークを書き出す)<\/>/SPAN >クライアント(JMeter)とサーバ(ArcGIS Server)が協調して展開スケーラビリティを検証可能<\/>/SPAN >クライアントはより多くの同時テストリクエスト送信、サーバはそれに応じて応答 全体テスト実行時間の最終結果がスケーラビリティ分析となる<\/>/U ><\/>/LI ><\/>/LI ><\/>/LI >Thread Group要素からスレッド数とRamp-up期間増加<\/>/SPAN ><\/>/LI >考慮事項<\/>/SPAN >CPUへの負荷 が高まるにつれてサービスインスタンスも増加<\/>/SPAN >サーバおよびテストクライアントマシン両方<\/>/SPAN ><\/>/LI >この高い同時実行率は他ユーザーへ影響 を与える可能性あり<\/>/SPAN >適切な調整とスケジューリングが必要<\/>/SPAN ><\/>/LI ><\/>/LI >ArcGIS Enterprise から返される応答時間の数値を通じてシステムがこの負荷にどのように反応するかを理解することは、展開がパフォーマンス要件を満たせるかどうかを判断するのに役立ちます。<\/P>作成されたテストは、時間（より多くの同時実行性、より高いスケーラビリティが必要）やリソースの課題（メモリ制約のあるシステム）に対応するよう調整可能です。<\/P>テスト結果の分析戦略も議論されており、JMeter テストプランの Aggregate Report を使用して迅速なパフォーマンス統計を取得したり、個々の応答時間をチャート化して視覚的に明確にしたりする方法が含まれています。<\/P>Update Subnetwork と Export Subnetwork のテストプラン全体のプロセスは類似していますが、Export Subnetwork には Groovy を使用して各サブネットワークのファイルサイズを取得し、ArcGIS Server 上で結果出力を検証する追加のトランザクションが含まれていました。<\/P>この記事で使用された Apache JMeter テストプランをダウンロードするには、以下をご覧ください:UpdateSubnetwork1.zip<\/A><\/STRONG><\/LI>ExportSubnetwork1.zip<\/A><\/STRONG> <\/LI><\/UL><\/LI><\/UL>
