为什么 AWS SQS 这么慢？答案

【问题标题】：Why is AWS SQS so slow?为什么 AWS SQS 这么慢？
【发布时间】：2018-04-01 02:29:14
【问题描述】：

我一直在测试从 SQS 队列发送和接收消息所需的时间。平均需要 800-1200 毫秒，这似乎是一个非常长的时间。这是我的测试代码，如果我做错了什么，请告诉我。

var t0;
sendMessage('hello');

function sendMessage(message){

    var params = {
        MessageBody: message,
        QueueUrl: queueUrl
    };
    t0 = now();
    sqs.sendMessage(params, function(err,data){
        if(err){
            throw err;
        } else {
            console.log("Message Send Confirmation");
        }
    });
    unbatch();
}

async function unbatch(){

    var params = {
        QueueUrl: queueUrl,
        MaxNumberOfMessages: 10
    };
    var go = true;
    while(go){
        console.log("Polling...");
        sqs.receiveMessage(params, function(err, data){
            if(data.Messages){
                console.log("Message Received");
                console.log("Total Time: " + ((now() - t0)/1000));
                go = false;
                var deleteParams = {
                    QueueUrl: queueUrl,
                    ReceiptHandle: data.Messages[0].ReceiptHandle
                };
                sqs.deleteMessage(deleteParams, function(err, data) {
                    if (err) {
                        console.log("Delete Error", err);
                    } else {
                        console.log("Message Deleted");
                    }
                });
            }
        });
        await sleep(1);
    }
}

function sleep(ms){
    return new Promise(resolve => setTimeout(resolve, ms));
}

它发送消息并立即开始尝试每毫秒接收一条消息。一旦收到，它就会计算时间。这不应该花费更少的时间吗？

【问题讨论】：

我写了一个“queue drainer”工具，它从 SQS 读取数据并将其存储在 MySQL 数据库中......它内置了一些聪明的地方，比如在获取下一个批次时异步删除前一个批次，但它仍然可以进行一些优化，我忘记了具体数字......但我几乎可以肯定它每秒可以消耗近 200 条消息......所以你的时间看起来确实有点不对劲，当然队列中有 10 条消息与只有 1 条消息相比，您将获得显着的 trx/sec 改进。你在哪里运行这段代码？在与队列相同区域的 EC2 中，还是在其他地方？
我并不关心它每秒可以处理多少条消息。我更关心单个消息的往返时间。另外，我是从本地系统运行的。
从本地系统运行会引入显着的延迟，因为您正在通过 TLS 向服务发送 HTTP，因此存在多次往返开销。提到每秒消息的重点不是服务的速度——它比这快得多——重点是如果我每秒处理超过 100 条消息，那么我必须在 10 毫秒内处理每条消息。我只有一个线程在运行。如果我将最大消息数设置为 1，我仍然会以大约 20 条消息/秒或约 50 毫秒的速度运行。从冷开始只做 1 件事的时间很少。
看起来您一次只处理一条消息，并且包括从本地计算机（而不是同一区域中的 EC2 实例）发送/接收消息的所有延迟。 SQS 未针对此用例（单个消息）进行优化 - 它针对许多消息吞吐量和弹性（至少一次传递）进行了优化。

标签： javascript node.js amazon-web-services amazon-sqs

【解决方案1】：

您使用任何队列的原因不是为了性能，而是为了弹性。

队列解决了许多问题，它们在断开连接的系统之间提供异步通信，它们允许您真正很好地扩展系统，并提供增强的弹性，确保在系统发生故障时消息不会“丢失”。

在使用队列时，您应该考虑围绕eventual consistency 的概念设计您的系统，这意味着您的消息最终会到达那里并得到处理，但可能不会在您期望的时间或什至按照您期望的顺序进行。

速度、排序、重试等功能会因队列实现（SQS、Kafka、RabbitMq 等）而异

如果您正在寻找超高 IOPS，那么队列可能不是您想要的。

【讨论】：

您对超高IOPS有什么建议吗？