ワークフロー - ABBYY Documentation

ワークフローの構成は、システムのパフォーマンスやハードウェアへの負荷に大きく影響します。以下では、Pre-processing、Recognition、Verification、Export の各ステージを含むデフォルトのワークフローで発生する負荷を前提に説明します。特定のプロジェクト要件に合わせて、処理ステージを追加したり、順序を変更したり、高度なルーティングルールを設定したりできます。その際は、次の点に注意してください。

ステージを増やしすぎない各ステージが増えるたびに、処理対象データのダウンロード、処理の実行、処理結果のサーバーへの返送などに必要なリソースも増え、結果としてプロジェクト全体のコストも上がります。たとえば、自動 script 用に新しい custom ステージを追加しようとしている場合は、その script を rules や事前定義イベントで実行できないか、あるいは既存の別のステージに組み込めないかを検討してください。
最も遅いステージがパフォーマンスの上限を決める通常、最も遅いのは手作業を伴うステージです。一方で、無人処理であっても、最適化されていないカスタムスクリプトや、キャッシュされていない外部 resources への低速なアクセスが原因で、ボトルネックが発生することがあります。最も遅いステージを特定するには、管理および監視コンソールを使用して、ワークフロー全体の各ステージにある queues を確認してください。ステージを高速化できないか、少なくともステージのプロパティにある “Documents per Task” オプションを使用して処理を並列化できないかを検討してください。
ステージで処理を並列化する場合、tasks を細かくしすぎないステージで処理を並列化する場合は、処理を細かく分割しすぎないようにしてください。各単位を処理するたびに、システム側の追加作業が発生します。特に、非常に小さな自動 tasks が大量にあると、各 task を executors に振り分ける Processing Server の処理が遅くなることがあります。たとえば、あるステージを単に 2 倍速くしたいだけで、通常 1 つの batch に 10 件の documents がある場合は、デフォルトどおり batch 全体を 1 つの task にする代わりに、5 件ずつ 2 つの sets に分けて task を作成すれば十分です。ただし、実際に必要がないのであれば、document ごとに 1 つの task を作成するのは避けてください。また、batch より小さい単位で task を作成すると、executor の柔軟性が制限される点にも注意してください。たとえば、scenario によっては verifier が各 document を個別に処理できる場合でも、自動 document assembly では、1 つの batch に含まれるすべての pages が 1 つの task にまとまっていることが非常に重要です。