SQSショートポーリングはロングポーリングよりも望ましいですか？
Amazon SQSは、利用可能なメッセージのポーリングの2つのモードをサポートしています。ショートポーリングとロングポーリングです。ロングポーリングでは、コンシューマは1〜20秒のタイムアウトを指定して、使用可能なメッセージを待機します。
ドキュメント によると：
デフォルトでは、Amazon SQSはshort pollingを使用して、サーバーのサブセットのみにクエリを実行し（加重ランダム分布に基づく）、メッセージが利用可能かどうかを判断します応答のため。
ロングポーリングには次の利点があります。
- Amazon SQSがメッセージをキューで使用できるようになるまで待機してから応答を送信できるようにすることで、空の応答を排除します。接続がタイムアウトしない限り、
ReceiveMessage要求への応答には、ReceiveMessageアクションで指定されたメッセージの最大数まで、使用可能なメッセージの少なくとも1つが含まれます。- Amazon SQSサーバーのサブセットではなく、すべてに対してクエリを実行して、空の誤った応答を排除します。
- メッセージが利用可能になり次第、メッセージを返します。
上記の特性により、ロングポーリングはかなり良いように見えます。それでは、短いポーリングが望ましいユースケースはありますか？
特に、高スループットキューの場合、ショートポーリングはロングポーリングよりも高速ですか？
ほとんどの場合、ロングポーリングはショートポーリングよりも望ましい方法です。以下は、短いポーリングが望ましい2つの使用例です（SQS FAQに記載されています）。
- 即時メッセージ処理が必要な場合。
- 1つのスレッドで複数のキューをポーリングする場合。
SQSから FAQs ：
ほとんどすべての場合、Amazon SQSロングポーリングはショートポーリングよりも望ましいです。ロングポーリングリクエストにより、キューコンシューマーはメッセージが返された空のReceiveMessageResponseインスタンスの数を減らしながらキューに入れます。
Amazon SQSのロングポーリングにより、大部分のユースケースで、コストを抑えながらパフォーマンスを向上させることができます。ただし、アプリケーションがReceiveMessage呼び出しからの即時応答を期待している場合、アプリケーションに変更を加えないと、長いポーリングを利用できない場合があります。
たとえば、アプリケーションが複数のキューをポーリングするために単一のスレッドを使用する場合、単一のスレッドが任意のロングポーリングタイムアウトを待機するため、ショートポーリングからロングポーリングへの切り替えはおそらく機能しません空のキュー、メッセージを含む可能性のあるキューの処理を遅らせます。
このようなアプリケーションでは、単一のスレッドを使用して1つのキューのみを処理することをお勧めします。これにより、アプリケーションはAmazon SQSロングポーリングが提供する利点を活用できます。