Benchmarking

[amineKammah]

As of this commit: https://github.com/amineKammah/ensimag-sdtd/commit/61f647b3e09252de53be6bb576ba997dc1e0787f

With 5 Spark executors, the average response time for processing one image is: 3.484 seconds. With 4 Spark executors, the average response time for processing one image is: 3.646 seconds. With 3 Spark executors, the average response time for processing one image is: 4.797 seconds. With 2 Spark executors, the average response time for processing one image is: 6.782 seconds.

[amineKammah]

To understand Spark Streaming: https://techmagie.wordpress.com/2017/04/22/spark-streaming-under-the-hood/

[amineKammah]

• Pour mesurer les capacités du systèmes, on a choisi de mesurer le temps de traitement moyen d’une image dans un batch de 100 images choisies aléatoirement.
• Dans un premier temps, on a envoyé 100 images à Spark une après l’autre. En conséquent, toutes les images ont envoyé au même exécuteur Spark même si on disposait de 5 exécuteurs.
• Ceci a révélé une limitation de Spark Streaming, en fait la répartition des taches sur les executeurs est détéminée par 2 paramètres, un interval de Batch, qui est la durée du micro-batch, et un interval de block. Toutes les images qui seront reçu pendant le même interval de block seront regroupé dans le même RDD, et traité par la suite par le même executeur. Ce qui explique pourquoi toutes les 100 images envoyé n’ont pas été distribués.
• Dans un deuxième Benchmark, on a envoyé une image au service toute les 200ms. C’est à dire on a assuré que chaque image envoyé sera contenu dans un RDD différent. Effectivement, on a réussi à distribuer le traitement de données, mais les gains en performances étaient non satifesantes. On s’attendait à des gains en performances presque parfaits vu que l’application est facilement parallélisable.
• Comme vous voyez avec 5 execteurs, on a peine pu mésurer une amélioration de 49% comparée à 2 execteurs
• Dans ce deuxième Benchmark, on envoyait une image chaque 200ms, Spark assigne un execteur pour chaque image une fois reçu, c’est à dire au bout de 20 secondes, toutes les images sont distribués sur touts les executeurs disponible. on finit généralement par une distruibution uniforme des images, par exemple avec 4 exécuteurs, chacun traite 25 images. Le problème c’est que pour quelques execteurs, ils finissent le traitement en 5 minuntes, d’autres, recevoient un batch qui contient beaucoup plus de text, et prennent 15 mins pour finir l’execution. Ceci entraine une grande perte de performance.
• Ceci ne sera pas un problème avec une application d’un très haut flux de données avec un petit temps de traitement. Mais Vu qu’on peut pas configurer le temps d’execution moyen dans Spark Streaming, il serait mieux d’utiliser une solution de distribution personnalisé autre que Spark Streaming.