Discussion :

[Yonito]

Salut tout le monde,

J'aurai une question a vous poser concernant un cache que nous avons ajouter dans notre application au travail (Application de trading pour banque).

En gros, nous avons une classe java qui s'appelle CCPairService qui possede une methode static buildCcPair(String) qui a pour but de recevoir un string qui represente un symbol de change comme "EUR/USD" ou bien "EUR/GBP" voir des symbols du genre "EUR/USD-1M" dont le 1M correspond a une periode de paiement (Cette liste de periode est relativement reduite - une quinzaine) et de renvoyer un object java nomme CCPair.

Chaque string de type "EUR/USD" est extrait de message recu via le protocole financier FIX envoye par un "liquidity provider" (pour faire court, une banque) et est passe en parametre a CCPairService.buildCcPair(String) pour nous renvoyer l'objet java CCPair lui correspondant.
La methode appele ne fait rien de plus que de parser le parametre string via splits et creer l'objet CCPair via un appel a son constructeur..

Pouvant recevoir jusqu'a 6 mille messages par seconde, il etait important pour nous de creer un cache sur cette methode (en pure java) via une map pour eviter le travail de split qui nous prend du temps. En effet nous essayons d'economiser la moindre micro seconde car le system doit etre au maximum realtime.

L'algorithme qu'on utilise est des plus simple :
1. On recherche dans une map si l'objet CCPair est deja cree via la cle qui est le parametre string.
2. Si oui on le renvoi, si non on execute le traitement de parsing puis ajoutons l'objet dans la map.
3. On renvoit l'objet CCPair

Nous n'effectuons aucune suppression de la map jusqu'au redemarrage du logiciel car le nombre de possibilites de CCPair est limitee (une centaine maximum).

Mes questions sont les suivantes :

Sachant qu'un thread correspond a un ensemble de message envoye par un liquidity provider (a peu pret 3 a 4 message par seconde) et qu'il existe beaucoup de liquidity providers dans notre systeme,

1. Est il preferable d'utiliser une HashMap ou un ConcurrentMap pour le cache ?
En theorie quand on parle de multithreading, nous devons utiliser une Map thread safe, mais vu que l'on ne fait aucune suppression de la map (put() et get() uniquement), est ce que cela est il toujours preferable ?
Pour moi si j'utilise une concurrentMap, je vais perdre le parrallelisme des appels a la map car elle va serialiser les appels a cette derniere vu que celle ci est thread safe et donc "perdre" du temps.

2. Y'a t'il un scenario qui doit quand meme me contraindre a utiliser une ConcurentMap ?
3. Avez vous peut etre une autre recommandation sur la maniere d'implementer un cache (en prenant bien sur en compte du caractere real time du systeme et en pure JAVA - pas de @cacheable etc)
4. Suggestion ? je suis preneur


Merci de votre collaboration et desole pour l'absence d'accent, j'utilise un clavier QWERTY.

[Cafeinoman]

Salut,

Au niveau des scénarios problématique, il y a simplement le put(). Au début, tu risques d'avoir des thread qui vont chercher dans le cache, ne pas trouver, et donc faire un put(). Sauf que pendant ce temps, un autre thread aura fait le put(). Tu perds des nanosecondes, mais ca semble important.
Ce que je ne comprend pas, c'est que tu n'as que quelques centaines variables. Pourquoi ne pas les mettre dans un fichier properties que tu parse au démarrage. Comme ca tu as tout ton cache dès le début, et tu peux utiliser une map non modifiable. Et comme c'est un gichier properties, tu peux eventuellement le modifier en cas de changements dans ton pool de variables, sans avoir de recompilation. Tu peux même créer une methode de reconstruction du cache, pour ne pas avoir a redémarrer l'appli (même si de facto la reconstruction bloquera les appel quelques millisecondes).

[Gugelhupf]

Salut,

Si le contenu de ta map est prévisible, tu peux générer l'ensemble de son contenu à l'avance pour ensuite y faire appel.
Si tu travailles dans un environnement multithread tu dois utiliser un concurrent hash map, aussi le fait d'utiliser une telle map ne casse pas le parallélisme dans le sens où seul l'opération put() est locké, et pas les opérations pour générer tes CCPair ou tes opération de lecture avec get()

[Yonito]

Salut,

Si le contenu de ta map est prévisible, tu peux générer l'ensemble de son contenu à l'avance pour ensuite y faire appel.
Si tu travailles dans un environnement multithread tu dois utiliser un concurrent hash map, aussi le fait d'utiliser une telle map ne casse pas le parallélisme dans le sens où seul l'opération put() est locké, et pas les opérations pour générer tes CCPair ou tes opération de lecture avec get()

La map n'est pas previsible a 100%. Tout dependra des liquidity providers connectes au meme moment.
Je ne savais pas que seul le put etait synchronize. Donc en effet si c'est seulement au premier appel que cela est serialiser, cela peut etre plus judicieux d'utiliser une concurrentMap.

Merci de ce detail important.

[bouye]

Voir aussi peut-être HashMap Vs. ConcurrentHashMap Vs. SynchronizedMap – How a HashMap can be Synchronized in Java

[tchize_]

Je vais poser d'abord deux questions. Est-ce que tu a la moindre mesure indiquant que ce parsing a une influence non négligeable sur ton programme? Genre ça bouffe 10% du temps d'exécution. Parce que si tu n'as pas de mesure de profiling tu oublie ton optimisation. Rien ne prouve qu'elle est soit necessaire soit efficace. D'abord on profile ensuite on ameliore le programme sur les points chauds identifies... Est-ce que tu as fais la moindre mesure complementaire démontrant que ton parsing est plus lent que la hashmap? Parce que vu le niveau basique de ton parsing et le fait que ta hashmap modifiable implique de la synchronisation. Soit le parsing est plus compliqué que tu ne le prétends, soit il est mal réalisé. Ce parsing peux se faire en parcourant 1 fois la string. Ta hashmap nécessitera deux parcours au minimum, un synchronized et le parcours des entrées liées à la clé de hashage...

[Yonito]

Salut,

Au niveau des scénarios problématique, il y a simplement le put(). Au début, tu risques d'avoir des thread qui vont chercher dans le cache, ne pas trouver, et donc faire un put(). Sauf que pendant ce temps, un autre thread aura fait le put(). Tu perds des nanosecondes, mais ca semble important.
Ce que je ne comprend pas, c'est que tu n'as que quelques centaines variables. Pourquoi ne pas les mettre dans un fichier properties que tu parse au démarrage. Comme ca tu as tout ton cache dès le début, et tu peux utiliser une map non modifiable. Et comme c'est un gichier properties, tu peux eventuellement le modifier en cas de changements dans ton pool de variables, sans avoir de recompilation. Tu peux même créer une methode de reconstruction du cache, pour ne pas avoir a redémarrer l'appli (même si de facto la reconstruction bloquera les appel quelques millisecondes).

Bonjour,

Je ne souhaite pas travailler avec un fichier et me soucier des autorisations en ecritures. De plus de ma partie du programme, je n'ai pas acces a la base de donnees pour creer le fichier. Ceci doit donc se faire "online".
Sachant qu'un meme objet CCPair peut avoir differentes cles dans la map "EUR/USD" mais aussi "EURUSD" par exemple. je ne veux donc pas imaginer toutes les possibilites qui peuvent etre different selon chaque liquidity provider pour initialiser la map au demarrage.