2 votes

Peut-il y avoir un retard lors de l'utilisation de ServiceBusTrigger dans les fonctions Azure sous le plan de consommation ?

J'ai l'intention d'utiliser ServiceBusTrigger dans les fonctions Azure. Je sais que dans le cadre du plan de consommation, les fonctions peuvent cesser de fonctionner en raison de l'inactivité après une certaine période de temps, comme cela est mentionné. ici .

Nous désallouons les ressources après environ 20 minutes d'inactivité. après quoi votre prochain appel sera un démarrage à froid

Disons que mon application de fonction a été arrêtée pour cause d'inactivité. Je comprends qu'un HTTPTrigger va se réveiller mon application. Elle sera lente en raison du démarrage à froid, mais au moins le délai ne sera que de la durée du démarrage à froid (quelques secondes en supposant une initialisation légère).

Questions

  1. Comment les ServiceBusTriggers sont-ils traités lorsqu'une application est désaffectée ? Si un nouveau message arrive, la fonction sera-t-elle déclenchée immédiatement ? La pénalité de démarrage à froid est acceptable, mais pourrait-elle être plus proche de quelques dizaines de minutes ? Voici commentaire sur les déclencheurs blob indiquent que cela peut prendre jusqu'à 10 minutes, mais je ne suis pas sûr que cela s'applique également à Service Bus.

    Si votre application de fonction est sur le plan Consommation, il peut y avoir jusqu'à un 10 minutes dans le traitement des nouveaux blobs si une application de fonction est restée inactif.

  2. En supposant qu'il puisse y avoir des retards de quelques dizaines de minutes, peut-on réduire ces retards en utilisant le plan Premium ou le plan App Service avec l'option "Always On" ?

0voto

Yuck Points 6730
  1. Vous faites référence à deux déclencheurs distincts : servicebus et blob. Les déclencheurs blob sont lents, mais certainement pas des dizaines de minutes. Les déclencheurs Servicebus sont très rapides.
  2. Oui, vous pouvez réduire le nombre de démarrages à froid en optant pour un plan d'entretien de l'application, mais je ne vois aucune indication que vous en tiriez profit. Vous pourriez gagner une seconde ou deux.

Il semble que vous rencontriez des problèmes de latence et que vous ne parveniez pas à identifier la cause première. Les déclencheurs sont rapides.

0 votes

Merci. À propos du point 1, cela signifie-t-il que même lorsque l'instance de l'application a été désallouée pour cause d'inactivité, il y a toujours quelque chose qui écoute les messages du bus de service ? J'ai introduit le commentaire sur les blobs pour décrire le fait que les déclencheurs de blobs sont également rapides lorsque l'application est en cours d'exécution, mais pas lorsqu'elle est désallouée. Et je me demande si la même chose peut se produire pour le bus de service. Je devrais peut-être tester cela :)

0 votes

Le décalage avec le blob triggered est dû au fait que les journaux du compte de stockage (listant les blobs actuels dans les conteneurs) sont mis à jour sur un intervalle de temps, lorsque vous utilisez le blob trigger, il est en fait déclenché par la mise à jour du journal, et non directement par le blob en cours de création

0 votes

Je suis conscient des démarrages à froid avec les déclencheurs http, cependant, je ne suis pas sûr qu'il y ait un décalage lorsqu'il s'agit de déclencheurs servicebus.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X