[OPTIMISATION] Trouver les goulots d'étranglement

[jean-pasqualini]

Goulots

• Le goulot d'étranglement du moteur de requête doctrine permet juste de passer de 1 minute à 23 seconde et est donc exclu (PAS FORCEMENT VU LA CONCLUSION)
• Le goulot d'étranglement du manque d'index sur l'ean (ajout d'un index pour solution) (passage de 400/s dégréssif à 1000/s)
• Le goulot d'étranglement qui vérifie si le produit existe permet de passer à 2500/s et semble donc d'intêret à analyser (usage d'un index local en mémoire plus rapide qu'un appel à la bdd à solutionner ce point) (empreinte mémoire plus importante en contrepartie à voir du coté d'un cache clé/valeur (redis/memcache) qui permettera également de partager ce cache pour une meuilleur scalabilité)
• Le goulot d'étranglement du serializer réduit le flow de 7200/s à 2500/s mais sera lui même limite par la performance du flush
• Le goulot d'étranglement du flush réduit à 2500 par seconde (qu'on ai un batch de 5000 ou de 50000) (la piste de l'insert étendu n'est pas si écarté que sa)
• Le goulot d'étranglement du process unique résolu par process isolé ou message queue ne semble pas être intéréssent car il est limité par les autres goulots d'étranglements.

Constat

On constate que c'est bien le couple du flush et de la désérialization qui divise les performance par 3.
Ainsi on met 1mn (2500/s) là on pour rais mettre 20 secondes (7200/s) pour 150 000 élements.

• Sans utiliser de sérializer et avec un système d'insert étendu on est à 7200/s
• L'usage du serailizer limite à 2500/s
• L'usage du flush avec insert classique limite à 2500/s

Piste

• Il faut monitorer par step le temps de traitement par itération et le temps d'attente pour calculer le potentiel de traitement suplémentaire
• J'ai l'impression que ces goulots d'étranglement empêche la scalabilité
  - si je met une queue pour un goulot d'étranglement sa reste bloquer sur l'autre
  - peut être une queue pour les deux queue pour différer les deux goulots à savoir une pour la serialization et une pour le flush
• Sinon l'usage d'insertion étendu avec du switch table pourrais être ne idée très intéréssente
• Il serait intêresent de pouvoir identifier ces goulot d'étranglement de manière bien plus intéréssente avec un système de stat où l'ont vois le nombre d'ack par seconde. (statsd ?) (il serait cool aussi en mode débug de pouvoir désactiver un noued pour constater en réel les effets)
• Pour les cas spéciaux peut être permettre de faire un INSERT/UPDATE DQL avec le mapping des entitié car doctrine ne permet pas de faire d'insert en DQL donc à creuser)
• Peut être faire un test sans sérialization avec un paralélisme uniquement sur le flush pour voir