filesystem_read（再帰的=true）で処理時間が長くなる場合の原因とIntegrateスペック変更の効果 – HULFT Square

質問

HULFT Square の filesystem_read を「構造」「再帰的=true」で実行した場合、同一 Workspace・同一 Integrateサービス・同一ファイル数・同一フォルダー構成であるにもかかわらず、処理時間に大きな差が生じることがあります。原因として何が考えられますか。また、Integrateサービスのスペックを変更することで処理時間の改善は期待できますか。

回答

■ 処理時間差の原因について

「再帰的=true」の場合、対象ディレクトリーの直下だけでなく、さらに下の階層のディレクトリー配下にも読み込みを行います。そのため、ディレクトリー直下のオブジェクト数が同一であっても、下位階層を含めた取得対象オブジェクト数が一致していない場合、処理時間に差が生じる可能性があります。

処理時間差を調査する際は、対象ディレクトリーの直下だけでなく、さらに下の階層のオブジェクト数も一致しているかご確認ください。

なお、下位階層を含めたオブジェクト数が同一であっても、処理時間差の明確な原因が特定できない場合があります。

■ filesystem_read の性能特性について

再帰的処理はオペレーションの性質上、処理時間が長くなりやすい傾向があり、処理時間はディレクトリー構成やオブジェクト数に影響されます。

filesystem_read を「構造」「再帰的=true」で実行すること自体に不具合情報はありません。

ファイル数・フォルダー数に応じた推奨値や目安となる数値は確認できていません。

■ Integrateサービスのスペック変更の効果について

filesystem_read 実行時にメモリやCPUが顕著に枯渇している場合は、Integrateサービスのスペック変更で処理速度の向上が見込めます。

ただし、メモリやCPUが枯渇していない状況では、スペック変更による明確な処理速度の改善は断言できません。

また、スペック変更は複数の処理を並行で動かす際に効果が期待できることが多く、単一処理の処理速度の向上にはあまり効果はありません。

補足

参考マニュアル：2.6.1.4.8.1 ファイルシステム読み取り処理

大量ファイルを対象とする場合、filesystem_read を使用せず「ファイル名一覧取得処理」コンポーネントを利用した再帰的スクリプト呼び出し方式がございます。