Contexte: nous disposons d'un environnement de traitement par lots ayant une architecture basée sur jms. Voici un bref travail de celui-ci.Performances réduites après la mise en œuvre de la sérialisation avro dans un environnement de traitement par lots basé sur jms
Nous avons 2 entrées files.one et une autre sortie. Sur la file d'attente d'entrée, nous avons un processeur simple, qui lit les enregistrements d'un fichier plat et divise le fichier en un groupe d'enregistrements appelés morceaux. En outre, pour chaque fragment, il génère un thread à partir d'un pool de threads, qui à son tour crée un objet Java pour chaque segment. Après cela, chaque objet est converti en une chaîne et ensuite converti en octets et envoyé à la file d'attente d'entrée. Du côté de la destination, nous avons des mdbs qui attendent les messages qui convertissent ensuite les octets en chaîne amd puis en objets java et commencent à traiter les morceaux. Après traitement, les résultats sont envoyés à la file d'attente de sortie qui est ensuite traitée par d'autres consommateurs.
Maintenant, afin d'améliorer les performances, nous avons présenté AVRO comme framework de sérialisation. Au lieu de convertir un morceau qui est un objet java en une chaîne et ensuite en octets, nous copions les données de chunk dans avro et en plus est sérialisé. De la même manière, nous convertissons les données sérialisées en blocs en utilisant la désérialisation avro. Après avoir fait cela, nous avons observé que nous étions en mesure de réduire la taille des données de chaque morceau de 30 pour cent. Auparavant, la taille du bloc était de 220000 octets, ce qui a été réduit à 150000 octets. Cependant, quand nous avons essayé de mesurer la performance en termes de temps pris par le processeur d'entrée pour traiter tous les morceaux, il a augmenté. Par exemple. plus tôt 6000 dossiers divisés en 60 morceaux de 100 tours ont pris 18 secondes. Maintenant, après avoir implémenté avro, cela prend 20-22 secondes. Questions: mesurer les performances de la manière ci-dessus dans le bon sens?
Quelles sont les autres façons de mesurer l'amélioration des performances dans le scénario ci-dessus. Apparemment, la taille du message a diminué, mais j'ai besoin de données solides pour prouver l'amélioration.
P.s. mon processus de réflexion pour utiliser le temps pris par le processeur d'entrée en tant que paramètre de performance est que s'il y a moins de données à écrire dans la file d'attente, les threads générés par le processeur pour traiter chaque segment seront libérés plus tôt. Ici, le nombre de threads engendrés est configurable. Dans les mesures ci-dessus, 2 threads ont été configurés dans le pool de threads.