2017-10-19 7 views
0

J'ai testé le temps nécessaire pour envoyer un message et le recevoir d'une file d'attente SQS. Cela prend en moyenne 800-1200 ms, ce qui semble ridiculement long. Voici mon code de test, s'il vous plaît dites-moi si je fais quelque chose de mal.Pourquoi AWS SQS est-il si lent?

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

Il envoie le message et commence immédiatement à essayer de recevoir un message toutes les millisecondes. Une fois reçu, il calcule l'heure. Cela ne devrait-il pas prendre beaucoup moins de temps?

+0

J'ai écrit un outil de "file d'attente" qui lit à partir de SQS et stocke le dans une base de données MySQL ... Il a une certaine intelligence, comme supprimer le lot précédent asynchrone tout en récupérant le lot suivant optimisation qui pourrait être fait, et j'oublie les chiffres spécifiques ... mais je suis presque certain qu'il peut consommer près de 200 messages par seconde ... donc vos temps semblent hors, un peu et bien sûr avec 10 messages en file d'attente vs juste 1, vous auriez une amélioration significative trx/sec. Où courez-vous ce code? Dans EC2 dans la même région que la file d'attente, ou ailleurs? –

+0

Je ne suis pas vraiment préoccupé par le nombre de messages par seconde qu'il peut faire. Je suis plus préoccupé par le temps d'aller-retour d'un seul message. En outre, je l'exécutais à partir de mon système local. – Matt

+1

L'exécution à partir de votre système local entraînera une latence importante, car vous utilisez le protocole HTTP sur TLS pour le service, de sorte qu'il y a plusieurs allers-retours de frais généraux. Le point de mentionner les messages par seconde n'est pas la rapidité du service - c'est beaucoup plus rapide que cela - le fait est que si je traite plus de 100 messages par seconde, alors je traite nécessairement chaque message en moins de 10ms. Je n'ai qu'un thread en cours d'exécution. Si je mets le nombre maximum de messages à 1, je brûle toujours environ 20 messages/sec, ou ~ 50ms. Temps de faire seulement 1 à partir d'un démarrage à froid révèle peu. –

Répondre

2

La raison pour laquelle vous utiliseriez une file d'attente n'est pas la performance mais la résilience. Les files d'attente résolvent de nombreux problèmes, elles fournissent des communications asynchrones entre systèmes déconnectés, elles vous permettent de très bien dimensionner les systèmes et offrent une meilleure résilience en évitant que les messages ne soient «perdus» en cas de défaillance du système. Lorsque vous travaillez sur des files d'attente, vous devriez envisager de concevoir votre système autour du concept eventual consistency, ce qui signifie que votre message finira par y être traité et traité, mais peut-être pas quand ou même dans l'ordre dans lequel vous vous attendez.

fonctionnalités telles vitesse, commande, etc. rejugeant varient entre les implémentations de file d'attente (SQS, Kafka, rabbitmq etc.)

Si vous recherchez IOPS super haut alors peut-être les files d'attente ne sont pas ce que vous voulez.