ブロッキング呼び出しパターンを使用すると、次のことが必要になります。
1. Listening on a socket vector of size N
2. When a message arrives, you wake up with a start in time K, find and start processing the message, employing a time T (it does not matter if the processing is offloaded to another thread: in this case T becomes your offloading time)
3. You finish examining the vector and GOTO 1
したがって、Mメッセージが到着し、K + M * Tディスパッチ時間中に別のメッセージが到着した場合、M+1番目のメッセージはK+M*T時間待機していることになります。これは、K(一定)、M(トラフィックの関数)、およびT(リソースとシステム負荷の関数)の期待値に対して許容できますか?
非同期処理は、まあ、実際には存在しません。どこかに常に「同期」IOループがありますが、それだけがカーネル(またはハードウェア)に十分に統合されているため、自分のIOループよりも10〜100倍高速に実行されるため、大きな値を使用すると拡張性が向上する可能性があります。遅延はまだK1+M * T1の形式ですが、今回はK1とT1がはるかに低くなっています。または、K1が少し高く、T1が大幅に低い場合があります。アーキテクチャは、Mの値が大きい場合に「より適切にスケーリング」します。
Mの値が通常低い場合、非同期性の利点は比例して小さくなります。アプリケーションの存続期間中にメッセージが1つしかないという不条理なケースでは、同期または非同期でほとんど違いはありません。
別の要因を考慮に入れてください。メッセージの数が非常に多くなる場合、非同期性には利点があります。ただし、メッセージ自体が独立している場合(メッセージAによって引き起こされた変更がメッセージBの処理に影響を与えない場合)、同期を維持して水平方向にスケーリングし、それぞれが分数M/Zを受け取る「メッセージコンセントレーター」の数Zを準備できます。総トラフィック。
処理で他のサービス(キャッシュ、永続性、情報取得、認証など)への他の呼び出しを実行し、Tファクターを増やす必要がある場合は、マルチスレッドまたは非同期に切り替える方がよいでしょう。マルチスレッドを使用すると、Tをその値の一部に削減できます(ディスパッチ時間のみ)。ある意味で非同期は同じことをしますが、さらにシェービングし、より多くのプログラミング定型文を処理します。