フローのチューニング

フローの特定のコンポーネントがボトルネックになっている場合、以下のチューニングポイントを確認します。

外部との通信設定

DB関連や各ネットワークプロトコル関連のコンポーネントでは、外部要因についても確認します。DB関連では、プールされていないコネクションを利用したアクセスはコストが高い傾向にあります。また、実行するSQLのチェックなども行います。各ネットワークプロトコル関連では、接続先サーバーのレスポンスなど外部連携の実行時間をチェックします。

コンポーネントの使い方

コンポーネントのヘルプからプロパティの設定などに問題がないかチェックします。ファイル入出力を伴うコンポーネントやストリームを変換するコンポーネントなどデータ形式やデータサイズによって処理時間が大きく異なります。

フローの処理ロジック

• ループ処理
  ループ処理が適切か確認します。大量レコードをループで１行ずつ扱う場合、ループせず一括でレコードを扱う場合に比べて処理時間がかかります。特にループを何重にも重ねている場合、遅くなる可能性があります。
• ループ処理とトランザクション化
  ループ処理を行っている場合に、フローをトランザクション化していない（開始コンポーネントの「トランザクション化」プロパティが「いいえ」）と、ループ回数分処理する各コンポーネントの実行ごとにコミットされます。フローをトランザクション化する（開始コンポーネントの「トランザクション化」プロパティを「はい」）と、ループ回数分処理する各コンポーンネントの実行が行われ、フローが正常終了すると最後に各コンポーネントが１度だけコミットされるため、コミットにかかる時間が短縮されます。
  特に影響があるのは、RDB 関連コンポーネントとFilePut コンポーネントのコミットです。可能であれば、フローのトランザクション化を検討します。トランザクションについては、「はじめに」＞「詳細なトピック」＞「トランザクション」を参照してください。
• 終了コンポーネント
  終了コンポーネントが適切か確認します。フローのレスポンスとしてストリームを返す必要がない場合、レスポンスとしてのストリームを作成しない、また、ストリームの受け渡しのコストがなくなるのでEndResponseコンポーネントではなくEndコンポーネントを使用することで改善されます。
• 全体の処理ロジック
  
• 処理ロジックが適切か確認します。処理中に同様な処理を複数行っている場合には１回の処理でまとめるように変更するなど、全体の処理ロジックを改善するよう見直します。
• フローの起動方法
  スケジュール起動の際に無駄な多重起動になっていないか、スケジュールの見直しなど行います。多重起動すると、ハードウェアスペックやフローサービスの各種設定の状態により、適切にフローを実行できない場合があります。後述のステータス確認方法で検証します。
• エラーの状況
  FlowService.log からエラーが発生していないか確認します。
• 処理の分岐
  ブランチやパラレル処理がある場合には想定どおりのコンポーネントが実行されているかログから確認します。