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