> ## Documentation Index
> Fetch the complete documentation index at: https://docs.abbyy.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Processing Station の数を計算する方法
> 1 コアあたりの処理時間を測定し、目標スループットに必要な ABBYY FlexiCapture Processing Stations と CPU コア数を計算します。
コンピューティングリソースを最大限に活用するため、各ステーションでは複数の処理スレッドが同時に実行されます。利用可能な CPU コア数が多いほど、より多くのスレッドを並列処理できます。CPU コア数はコンピューターごとに異なるため、FlexiCapture システム 内の**処理用 CPU コアの総数**を基準に考えるのが合理的です。
システム にボトルネックがなければ、新しい処理コアが 1 つ追加されるたびに、全体的なパフォーマンスに同等の効果をもたらします。したがって、まず 1 コアあたりの処理能力を見積もり、そのうえで目標のパフォーマンスに到達するのに必要なコア数を算出できます。
一定時間内に 1 つのコアが処理できるページ数は、処理 ワークフロー (たとえば、ステージ 数) 、処理設定 (画像補正、Recognition モード、Export settings) 、カスタム ステージ の実装 (カスタム engines や script rules、外部 resources への access) 、およびハードウェアに大きく左右されます。これらについてのデータがまだないものの、おおよその見積もりが必要な場合は、以下のグラフを目安として使用してください。ただし、実際のプロジェクトでは異なる結果になる可能性が高いでしょう。
上記の基準は、“SingleEntryPoint” Demo プロジェクト (無人処理、PDF ファイルへのエクスポート) を使用し、白黒ページでは 2.4 GHz、16 GB RAM、SSD、1 Gb/s NIC を備えた 10 コアの processing stations を前提としています。
## 処理コア数を見積もる
まず、1つのコアで1ページを処理するのにかかる時間を測定し、その値で目標処理量を割ります。
1. プロジェクトのワークフローを設定し、本番環境の構成に最も近いハードウェアの Processing Station を選択して、典型的な画像バッチを作成します。
2. 1つのコアで1つのバッチを処理するのにかかる時間を測定します。バッチを1回だけ処理しても十分ではありません。テスト中は FlexiCapture が利用可能なすべてのコアに処理を分散するため、バッチは、本番環境で他のコアが別のバッチの処理で使用中の場合よりも早く完了します。信頼できる値を得るには、典型的なバッチのコピーを複数作成してください。少なくともコア数と同じ数、理想的にはその N 倍 (N ≥ 3) です。そして、それらをすべて同時に処理します。1コアあたりの1バッチの処理時間は、総処理時間を N で割った値であり、これにはコア同士が ステーション の共有リソースを競合する影響も含まれます。
3. 必要なコア数を計算します。
```text theme={null}
N = (P × t) / T
```
ここで、P は処理するページ数、t は1ページを処理する時間、T は利用可能な時間です。
### 計算例
* Hyper-Threading を備えた 8 コアの Processing Station では、**16 個の論理コア** (16 個の実行プロセス) が利用できます。
* 一般的なバッチのコピーを **16 × 3 = 48** 個作成し (測定誤差を減らすために ×3) 、それらをすべて一度に処理します。
* 実行時間は **15 分** です。各コアで 3 つのバッチを処理するため、1 つのバッチの処理時間は約 **5 分** です。
* このバッチは **69 ページ** あるため、1 ページあたり約 **4.35 秒** かかります。
* **8 時間で 200,000 ページを処理**するには (28,800 秒) 、N = (200,000 × 4.35) / 28,800 ≈ **31 コア** となります。
* したがって、自動処理には **Hyper-Threading を備えた 8 コアの Processing Station 2 台** (合計 32 論理コア) で十分です。
## 制限要因
システム で有効に利用できる処理コア数を制限する要因は 2 つあります。
### インフラストラクチャの負荷
インフラストラクチャ全体の負荷により、次の箇所でボトルネックが発生する可能性があります。
* FlexiCaptureサーバーのハードウェア
* ネットワーク
* カスタム処理スクリプトからアクセスされる外部の共有リソース (データベースや外部サービスなど)
ボトルネックが発生すると、パフォーマンスは飽和します。つまり、処理コアをさらに1つ追加しても、全体のパフォーマンスに悪影響が出るか、まったく効果がなくなります。このガイドでは、ボトルネックを回避するためのシステムの設計方法と、ハードウェアおよびインフラストラクチャを監視してボトルネックを特定する方法について説明します。
明確なボトルネックが検出されていない場合でも、コアを追加するにつれて、共有リソースをめぐる処理コア間の競合は増大します。ネットワークまたはFileStorageの読み取り/書き込み容量の50%を超えて使用する見込みがある場合は、上記の例におけるページあたりの処理時間に20%を加算してください。すると、必要な処理コア数もおよそ20%増えることになります。
処理コアが外部リソースにより速くアクセスできるようにするには、キャッシュを使用してください。たとえば、データベースに直接接続する代わりに、FlexiCaptureデータセットを介して接続し、スクリプトからそのデータセットをリクエストします。
### Processing Server capacity
Processing Server で処理できる処理コア数には上限があります。この数は、1 つのコアが task を実行するのに要する平均時間に左右され、その平均時間は バッチ size (ページ数) や実装したカスタマイズの内容に大きく依存します。通常、1 バッチあたり約 10 ページの場合、Processing Server は 120 個の処理コアに対応できます。非常に高速な script を含むカスタム ステージ を多数作成したり、1 バッチあたり 1 ページで処理したりすると、task の平均処理時間が大幅に短くなり、その結果、Server が処理できるコアの最大数がわずかに減少することがあります。
これを確認するには、Processing Server の空き処理コア数を監視します。処理待ちの documents の queue があるにもかかわらず、使用中のコア数が飽和状態に達し、ほとんど増えなくなっている場合は、この上限に達しています。これを解消するには、次の対応を行ってください。
* 可能であれば、バッチ 全体を小さな tasks に分割せずに処理します (Workflow settings ダイアログの Stage Properties を参照) 。
* より大きな単位でページを処理します。1 バッチあたりの平均ページ数を増やす、複数のカスタム ステージ を 1 つにまとめる、またはカスタマイズを標準 stage に移す方法があります。たとえば、その stage の script のルーティングイベントに追加できます。