J'ai un WebJob Azure qui parcourt les pages d'un fichier et les traite. Le travail a également un ICollector à une file d'attente de sortie:Azure WebJob Sortie La liste des messages à mettre en file d'attente via ICollector semble lente
[Queue("batch-pages-to-process")] ICollector<QueueMessageBatchPage> outputQueueMessage
-je attendre jusqu'à ce que toutes les pages sont traitées avant d'envoyer tout à la file d'attente de sortie, donc au lieu d'ajouter chaque message au ICollector dans mon dossier boucle de traitement, j'ajouter les messages à une liste de messages de file d'attente:
List<QueueMessageBatchPage>
Après toutes les pages ont été traitées, je boucle puis à travers la liste et ajouter les messages au ICollector:
foreach (var m in outputMessages)
{
outputQueueMessage.Add(m);
}
Mais cette dernière partie semble prendre beaucoup de temps. Pour ajouter 300 messages de file d'attente, cela prend presque 50 secondes. Je n'ai pas grand chose à évaluer, mais cela semble lent. Est-ce normal?
Merci pour votre contribution Josh. Ma classe POCO de QueueMessageBatchPage est minuscule, 4 propriétés (2 ints, 2 chaînes). J'ai déjà essayé de paralléliser le traitement en décomposant le PDF en pages puis en traitant chaque page séparément avec un autre travail. Parce que je dois préparer chaque page du PDF d'entrée et le raser, je ne suis pas sûr de savoir comment décomposer ce processus initial. Toutes mes ressources d'azur sont dans l'Ouest américain. –
Salut Bryan ... donc j'étais curieux et j'ai décidé d'essayer une démo rapide pour modéliser ta situation et voir ce que j'ai trouvé. J'ai écrit un petit WebJob pour déclencher à partir d'un message de file d'attente et attraper un gros blob, puis le décomposer en blobs plus petits réécrits en mémoire, chacun ayant un message de sortie correspondant à une autre file d'attente. J'ai utilisé des fichiers texte au lieu de fichiers PDF ... bref, l'ensemble est très rapide. Bien sûr, le contenu et la taille des données peuvent être très différents de votre situation. N'hésitez pas à jeter un coup d'oeil et voir si cela aide. https://github.com/jplane/SO.WebJob.Demo – JoshL
Wow, merci pour l'effort supplémentaire. Je suppose que je dois faire d'autres tests pour identifier d'où le ralentissement pourrait provenir. C'est étrange cependant, j'ai utilisé un chronomètre chronomètre juste avant et après ma boucle foreach outputMessages et cela a mesuré 50+ secondes pour 300 messages. Je vois que vous avez utilisé Azure Storage 6.0.2 dans votre test. Je pensais que l'équipe WebJobs SDK définissait la limite de dépendance à 5.0.2, donc je n'ai pas mis à jour. Je me demande si cela entre en jeu. –