メインコンテンツへスキップ
コンピューティングリソースを最大限に活用するため、各ステーションでは複数の処理スレッドが同時に実行されます。利用可能な CPU コア数が多いほど、より多くのスレッドを並列処理できます。CPU コア数はコンピューターごとに異なるため、FlexiCapture System 内の処理用 CPU コアの総数を基準に考えるのが合理的です。 System にボトルネックがなければ、新しい処理コアが 1 つ追加されるたびに、System 全体のパフォーマンスに同等の効果をもたらします。したがって、まず 1 コアあたりの処理能力を見積もり、そのうえで目標のパフォーマンスを達成するのに必要なコア数を見積もる必要があります。 一定時間内に 1 つの処理コアが処理できるページ数は、処理 workflow (例: ステージ 数) 、処理設定 (画像補正の operation、Recognition モード、Export settings) 、カスタム ステージ の実装 (カスタム Engine や script rules、外部 resources へのアクセス) 、およびハードウェアに大きく左右されます。これらの詳細がまったくわからないものの、概算が必要な場合は、以下のグラフを目安として使用できます。ただし、実際のプロジェクトでは異なる結果になる可能性が高いでしょう。 処理コア数に対するパフォーマンスの依存関係 構成 “SingleEntryPoint” Demo プロジェクト: 無人処理、PDF ファイルへのエクスポート。 白黒ページの場合: 10 コアの Processing Station、2.4GHz、16GB RAM、SSD、1 Gb/s NIC。 必要な処理コア数を見積もるには、次のようにします。
  1. プロジェクトの workflow を構成し、本番環境で使用予定のハードウェアパラメーターに最も近い Processing Station を用意して、代表的な画像のバッチ を作成します。
  2. 1 コアで 1 バッチ を処理するのにかかる時間を測定します。 1 回だけ 1 バッチ を処理しても十分ではありません。FlexiCapture は利用可能なすべてのコアに処理を分散することがあるため、テスト中は 1 バッチ の処理時間が短く見えても、実際の本番環境では他のコアが別の batches の処理で使用されているためです。 信頼できる見積もりを得るには、代表的な バッチ のコピーを複数作成することをお勧めします。少なくともコア数と同じ数、できれば測定誤差を最小限に抑えるために N 倍 (N は少なくとも 3) 作成し、それらすべてを同時に処理に回します。この場合、1 コアあたり 1 バッチ の処理に必要な時間は、総処理時間を N で割った値になります。この見積もりでは、Processing Station の共有リソースをめぐる処理コア間の競合の可能性も考慮されます。 例。Hyper-Treading が有効な 8 コアの Processing Station があり、このステーションでは 16 個の論理コアと実行プロセスが得られるとします。代表的な バッチ のコピーを少なくとも 16 個作成する必要がありますが、測定誤差を最小限に抑えるには 16 x 3 = 48 個作成するのが望ましいです。すべての batches を FlexiCapture の hotfolder に入れ、最初の import task が作成された時点でタイマーを開始し、最後の結果がバックエンドにエクスポートされた時点で停止すると、15 分かかりました。この時間内に各コアは 3 batches を処理するため、1 バッチ の処理時間は約 5 分です。バッチ には 69 ページあるため、1 ページの処理には 4.35 秒かかると言えます。
  3. 1 時間あたりまたは 1 日あたりの必要なパフォーマンスがわかれば、必要なコア数を見積もることができます。 P ページを T 時間で処理する必要があるとします。上記より、1 コアが 1 ページを処理するには t 時間必要であることがわかっています。したがって、必要なコア数は N = (P x t ) / T です。 例。ある顧客が 8 時間で 200,000 ページを処理する必要があるとします。これは 28,800 秒です。上記より、1 コアが 1 ページを処理するのに 4.35 秒かかることがわかっています。したがって、必要なコア数は (200,000 x 4.35) / 28,800 = 31 コアです。したがって、8 コアで Hyper-Threading が有効な 2 台の Processing Stations (合計 32 論理コア) があれば、自動処理には十分です。
System 内の処理コア数に関しては、2 つの制限要因があります。
  1. ボトルネックの原因となる可能性があるインフラストラクチャ全体の負荷:
      • FlexiCapture サーバーのハードウェア上の負荷;
      • ネットワーク上の負荷; または
      • カスタム処理スクリプトから要求される外部の共有リソース (データベース、外部サービスなど) 上の負荷。
ボトルネックが発生すると、パフォーマンスは飽和状態になります。新しい処理コアを追加しても、全体的なパフォーマンスには悪影響が出るか、まったく効果がなくなります。このドキュメントでは、ボトルネックを回避するための System の設計方法 (上記を参照) と、ハードウェアおよびインフラストラクチャのボトルネックを監視する方法について説明します。 それでも、明確なボトルネックが検出されていない場合でも、System に新しいコアを追加すると、共有リソースをめぐる処理コア間の競合は増大します。ネットワークまたは FileStorage の読み取り/書き込み容量の 50% を超えて使用する場合は (このドキュメントの計算による) 、上記の例における各ページの処理時間に 20% を上乗せしてください。実際には、そのぶん System で必要な処理コア数も 20% 増えることになります。 処理コアから外部リソースへより高速にアクセスできるよう、キャッシュを使用してください。たとえば、データベースに直接接続する代わりに FlexiCapture Data Set に接続し、その後スクリプトから Data Set を要求します。
  1. Processing Server が対応できる処理コア数。この数は、1 つのコアがタスクを実行するのに必要な平均時間に左右されます。この時間は、バッチサイズ (ページ数) や実装されているカスタマイズに大きく依存します。通常、1 バッチあたり約 10 ページであれば、Processing Server は 120 個の処理コアに対応できます。ただし、非常に高速なスクリプトを含む多数のカスタムステージを作成したり、1 バッチあたり 1 ページを処理したりすると、タスクの平均時間が大幅に短くなり、その結果、処理コアの最大数がわずかに減少することがあります。
この問題を検出するには、Processing Server の Free Processing Cores カウンターを監視する必要があります。それにもかかわらず、処理待ちのドキュメントのキューがあり、使用中のコア数がある時点で飽和に達して以降ほとんど増えない場合は、ここで説明している状態が発生しています。これを解消するには、次のようにします。
  • 可能な場合は、バッチ全体を小さなタスクに分割せずに処理します (Workflow settings ダイアログの Stage Properties を参照) 。
  • より大きな単位でページを処理します。1 バッチあたりの平均ページ数を増やす、複数のカスタムステージを 1 つにまとめる、またはカスタマイズを標準ステージに組み込みます。たとえば、そのステージのスクリプト内のルーティングイベントに追加します。