Scaling
ワークフロー
ステージ数を抑え、最も遅いステージに対処し、並列タスク のサイズを適切に設定することで、ABBYY FlexiCapture のワークフロー構成を最適化し、パフォーマンスを向上させます。
ワークフローの構成は、システムのパフォーマンスやハードウェア負荷に大きく影響します。公開されているすべてのパフォーマンス値は、Pre-processing、Recognition、Verification、Export の各ステージを含むデフォルトのワークフローを前提としています。
特定のプロジェクト要件に合わせて、処理ステージを追加したり、順序を変更したり、高度なルーティング ルールを設定したりできます。その際は、次のガイドラインを念頭に置いてください。
各ステージでは、処理対象のデータをダウンロードし、処理して、結果をサーバーに返します。これら3つの処理はいずれもリソースを消費するため、ステージを追加するたびにプロジェクト全体のコストも増加します。
たとえば、自動スクリプトを実行するカスタムステージを追加したい場合があります。その前に、ルールまたは事前定義イベントからそのスクリプトを実行するか、既存のステージに組み込むことを検討してください。
最も遅いステージが、全体のパフォーマンスの制約になります。最も遅いのは通常、手作業が必要なステージです。無人処理でもボトルネックが発生します。主な原因は、効率の悪いカスタム スクリプトや、キャッシュされていない外部リソースへのアクセスの遅さです。
管理および監視コンソールで各ステージのキューを確認し、最も遅いステージを特定します。次に、そのステージを高速化するか、少なくともステージのプロパティにあるタスクごとのドキュメント数オプションを使用して並列化してください。
あるステージで処理を並列化する場合は、細かく分割しすぎないでください。各部分を処理するたびに、システム側で追加の作業が発生するためです。特に、非常に小さい自動タスクが大量にあると、それらを executor に振り分ける Processing Server の処理が遅くなることがあります。
通常 1 つのバッチに 10 個のドキュメントが含まれており、ステージを 2 倍高速に実行したいとします。5 個のドキュメントずつ 2 つのタスクで十分です。デフォルトでは、バッチは 1 つのタスクとして処理されます。必要がない場合は、ドキュメントごとに 1 つのタスクを作成しないでください。
バッチより小さいタスクでは、executor が実行できることも制限されます。verifier はドキュメントを 1 つずつ処理できます。自動ドキュメントアセンブリでは、1 つのバッチ内のすべてのページを 1 つのタスクに含める必要があるため、それはできません。