2017-10-19 11 views
0

メッセージを送信してSQSキューから受信するまでにかかる時間をテストしました。平均800-1200ミリ秒かかりますが、これは非常に長い時間のようです。ここで私のテスト用のコードは、私が何か間違っているかどうか教えてください。AWS SQSはなぜとても遅いのですか?

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)); 
} 

メッセージを送信し、すぐにメッセージを受信しようとします。受信すると、時間が計算されます。この時間が大幅に短縮されるべきではありませんか?

+0

私はSQSから読み込んでMySQLデータベースに格納した「キュー排水器」ツールを書いています...次のバッチをフェッチしながら前のバッチを非同期に削除するようないくつかの巧みさが組み込まれていますが、私は特定の数字を忘れています...しかし、私はほぼ毎秒200のメッセージを消費することができると確信しています...あなたの時間は、少し、そしてもちろんキューで10のメッセージ1と比べて、trx/secの大幅な改善が見込まれます。このコードをどこで実行していますか?キューと同じリージョンのEC2、または他の場所? –

+0

私はそれができる1秒あたりのメッセージの数に本当に関わっていません。私は、単一のメッセージの往復時間にもっと関心があります。また、私はローカルシステムからこれを実行していました。 – Matt

+1

ローカルシステムから実行すると、サービスに対するHTTP over TLSを使用しているため、かなりの遅延が発生するため、オーバーヘッドの複数ラウンドトリップが発生します。 1秒あたりのメッセージ数を言及する点はサービスの速度ではなく、それよりもはるかに高速です.1秒あたり100メッセージを処理している場合、必ず10ミリ秒以下で各メッセージを処理しています。私は1つのスレッドを実行しているだけです。メッセージの最大数を1に設定すると、まだ約20個のメッセージ/秒、つまり〜50msのメッセージが出ます。寒いスタートからちょうど1回する時間はほとんどない。 –

答えて

2

キューを使用する理由は、パフォーマンスのためではなく、回復力のためです。

キューは多くの問題を解決し、接続されていないシステム間で非同期通信を提供し、システムの拡張性を高め、システムの障害発生時にメッセージが失われないようにします。

eventual consistencyという概念を使用してシステムを設計することをお勧めします。メッセージが最終的にそこに到達して処理されますが、期待した順序で処理されない場合もあります。あなたは超高IOPSを探しているなら

能力、速度、順序付け、再試行などは、キューの実装(SQS、カフカ、RabbitMQのなど)

の間で変化するであろう、おそらくキューは、あなたが望むものではありません。

関連する問題