Présentation LMAX / Disruptor
Upcoming SlideShare
Loading in...5
×
 

Présentation LMAX / Disruptor

on

  • 967 views

Présentation de LMAX / Disruptor chez So@t par Cédric Finance et François OSTYN

Présentation de LMAX / Disruptor chez So@t par Cédric Finance et François OSTYN

Statistics

Views

Total Views
967
Views on SlideShare
961
Embed Views
6

Actions

Likes
2
Downloads
15
Comments
0

2 Embeds 6

http://www-rec.soat.fr 3
http://www.soat.fr 3

Accessibility

Categories

Upload Details

Uploaded via as Apple Keynote

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • \n
  • F + C\n
  • \n
  • F\n
  • F\n
  • F\n
  • C\n
  • F\n
  • Poser la question sur qui utilise la concurrence sur ses projets ?\n
  • C\n
  • F\n
  • C\n
  • C\n
  • C\n
  • C\n
  • F\n
  • F\n
  • F\n
  • C\n
  • C\n
  • C\n
  • C\n
  • C\n
  • F + C\n
  • F\n
  • F + C\n
  • F + C\n
  • F + C \n
  • F + C \n
  • F + C\n
  • F + C \n
  • NOP\n

Présentation LMAX / Disruptor Présentation LMAX / Disruptor Presentation Transcript

  • Le framework LMAX / Disruptor par Cédric FINANCE et François OSTYN cedric.finance@soat.fr / francois.ostyn@soat.fr 26 janvier 2012
  • Qui sommes nous ?
  • Introduction :
  • LMAX :Société spécialisée dans le passage d’ordres de bourse.Affichage temps réel des cotations, volume de transactions élevé,respect de l’ordonnancement des ordres et temps d’exécutionréduit.
  • Disruptor (replicator) :arme ayant été utilisée pour détruire les réplicateurs dans Stargate SG1
  • Disruptor :Framework de programmation concurrente. Résultat desrecherches de la société LMAX.
  • Le cloud, j’le casse- On se base sur le principe de l’IoA (Inversion of Architecture).- Pourquoi ne pas utiliser le maximum de puissance CPU et lamémoire de nos machines ?- Toutes ces architectures par strates sont compliquées non ?
  • La soirée 3T va devenirUT (Ultimate Technical):
  • Mais pourquoi la gestion de laconcurrence en Java est sicompliquée ? Attention, ces 384 pages sont dangereuses !!!
  • L’ordre :// ordre de programmation // ordre d’exécution (non certain) int w = 10; int y = 30; int x = 20; int x = 20; int y = 30; int b = x * y; int z = 40; int z = 40; int a = w + z; int w = 10; int b = x * y; int a = w + z;De nombreux facteurs peuvent influer : le matériel, lesparamètres de la JVM, le type de GC,... merci je JIT
  • Avant de continuer quelques chiffres :L1 cache reference 0.5 nsBranch mispredict 5 nsL2 cache reference 7 nsMutex lock/unlock 25 nsMain memory reference 100 nsCompress 1K bytes with Zippy 3,000 nsSend 2K bytes over 1 Gbps network 20,000 nsRead 1 MB sequentially from memory 250,000 nsRound trip within same datacenter 500,000 nsDisk seek 10,000,000 nsRead 1 MB sequentially from disk 20,000,000 nsSend packet CA->Netherlands->CA 150,000,000 ns
  • Il faut faire attention aux détails :Incrémenter un compteur : Utiliser un lock : public static long foo = 0;static long foo = 0; public static Lock lock = new Lock();private static void increment() { private static void increment() { for (long l = 0; l < 500000000L; l++) { for (long l = 0; l < 500000000L; l++) { foo ++; lock.lock();} try { foo++; } finally {Utiliser un AtomicLong : lock.unlock(); }}}static AtomicLong foo = new AtomicLong(0);private static void increment() { for (long l = 0; l < 500000000L; l++) {foo.getAndIncrement();}}
  • Le coût des contentionsIncrémenter un compteur 500 millions de fois...● One Thread! :! 300 ms● One Thread (volatile):! 4 700 ms (15x)● One Thread (Atomic) : 5 700 ms (19x)● One Thread (Lock)!: 10 000 ms (33x)● Two Threads (Atomic) : 30 000 ms (100x)● Two Threads (Lock)!: 224 000 ms (746x)Soit pas loin de 4 minutes
  • Découper des chaînes de caractères● Parallel (Scala): 440 ops/sec● Serial! (Java) : 1768 ops/secLa parallélisation des traitements n’est pas toujours une bonne solution
  • Et quid des processeurs ?Comparaison du temps de découpage des chaines de caractèresen mono-thread sur différents processeurs. Les performances peuvent aller du simple au double...
  • Mais que peut nous apporter le Disruptor... A part nous sauver des réplicateurs... (Private JOKE)
  • Ne pas devoir recourir à une architecture multi-threadDonc, une mise en place plus aiséeDe la simplicité pour les testsUn coût de machines moins élevéSe remettre en question sur le fonctionnement de Java...
  • Les problématiques rencontrées par la société LMAX - False sharing - Memory barrier - Context switch - CAS (compare and swap) - Cache line
  • le False sharing public void run() { long i = ITERATIONS + 1; while (0 != --i) { longs[arrayIndex].value = i; } } public final static class VolatileLong { public volatile long value = 0L; public long p1, p2, p3, p4, p5, p6; // comment out }
  • le False sharing
  • le False sharingPourquoi ce tel changement de performances?
  • le False sharing
  • le False sharing Header data1 data2 p1 p2 p3 p4 p5 Cache Line
  • Les conclusions que l’on peut tirer...Les queues (java) sont coûteuses (temps de traitement et lock des ressources)Le multi-threading est coûteux (contentions sur les ressources communes) et difficile a mettre en œuvre.Le multi-threading n’est pas le plus efficace en terme de performances. Attention, ce cas d’utilisation ne peut pas convenir à tout le monde...
  • Ce qu’a fait LMAX :Ecriture d’un framework permettant de partager rapidement les données entre thread sans toutefoisrecourir aux mécanismes classiques des locks. C’est ce que nous nommerons Disruptor.
  • Le pattern Disruptor : Les producteurs, le Ring Buffer et les consommateurs sont chacun dans des threads différents. Les acteurs : Producteur, Consommateur Les objets : RingBuffer, Barrier Les stratégies : Wait, ClaimObjectif : ne plus avoir de contentions...
  • Alors qu’avec une architecture classique nous avions : Mais où se trouve ma contention...
  • Ce que peut apporter le disruptor ? C’est mieux mais toujours pas parfait....
  • Mais est-ce vraiment rapide ?Conclusion : jusqu’à 5 fois plus rapide... et combien de fois moins cher (maintenance,matériel,...) et plus constant...
  • ...DEMO...Comment aider le GIE portabilité ? (pour toi Xavier...)
  • Conclusion- Ne jamais croire ce que l’on nous dit, il faut tester, expérimenter, la pratique estsouvent très loin de la théorie- La concurrence est un outil à manier avec précautions,...- Pour avoir des performances, chaque détail compte, mais comme le dit DonaldKnuth, «premature optimization is the root of Evil»
  • Liens :•http://www.infoq.com/articles/memory_barriers_jvm_concurrency•http://www.cs.virginia.edu/kim/publicity/pldi09tutorials/memory-efficient-java-tutorial.pdf•http://www.slideshare.net/trishagee/understanding-the-disruptor•http://code.google.com/p/disruptor/•http://disruptor.googlecode.com/files/Disruptor-1.0.pdf•http://mechanical-sympathy.blogspot.com/2011/07/false-sharing.html•http://mechanical-sympathy.blogspot.com/2011/07/memory-barriersfences.html•http://martinfowler.com/articles/lmax.html