According to the result, SQS will not be the best choice if we expect low Message delivery time.
There are a set of configuration available to control message delivery behavior, See http://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-long-polling.html
@Richard. Yes, it's true AWS SQS has high throughput for writes and read messages.
But in this experiment, I considered some practical requirement, the message latency (message round trip time), the time taken for a message to get from producer to consumer.
AWS SQS allows high throughput of writes, but it does not mean messages are instantly available for consumers/readers. There is no any documentation available about technical background of AWS SQS. It seems AWS SQS employ some technique as distributed hash tables (may be the same technical approach that AWS dynamodb uses.)
CORE
Comments
Apr 09, 2017 · Pradeep Peiris
According to the result, SQS will not be the best choice if we expect low Message delivery time.
There are a set of configuration available to control message delivery behavior, See http://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-long-polling.html
http://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-message-timers.html
(In the experiment, the default setting was used.)
Apr 09, 2017 · Pradeep Peiris
@Richard. Yes, it's true AWS SQS has high throughput for writes and read messages.
But in this experiment, I considered some practical requirement, the message latency (message round trip time), the time taken for a message to get from producer to consumer.
AWS SQS allows high throughput of writes, but it does not mean messages are instantly available for consumers/readers. There is no any documentation available about technical background of AWS SQS. It seems AWS SQS employ some technique as distributed hash tables (may be the same technical approach that AWS dynamodb uses.)