Les développeurs de LMAX Exchange, une plateforme d'exécution d'ordres sur le FOREX établie à Londres en octobre 2010, ont commencé à évaluer la JVM Zing d'Azul comme moyen d'améliorer leur latence et débit déjà impressionnants.
LMAX Exchange est devenu célèbre, même en dehors des service financiers, au moins en partie à force de vouloir parler publiquement de leurs choix technologiques. La firme a libéré le code source d'un composant clé de sa pile technique, le Disruptor, en mars 2011 et a présenté à QCon et d'autres conférences son travail.
A la fin de l'année, LMAX Exchange a terminé la dernière mise à jour de son data center de production, passant de serveurs Hewlett-Packard avec des processeurs Intel Hexacore Dunnington à des Dell 520 et 720 double socket avec des CPUs 8 core Intel Sandy Bridge. Les Dell ont respectivement 64 and 128 Go de mémoire. "Ce sont des serveurs de grande série, sans beaucoup de tuning spécifique", ("The servers are commodity, with not much specific tuning"), a déclaré Michael Barker, Head of Software à LMAX Exchange, a InfoQ.
Pour notre système critique de stockage journalisé, nous utilisons des disques 15k SAS en RAID ainsi qu'un cache en écriture avec batterie. Les tests que nous avons fait ont montrés qu'un ensemble RAID était autant ou plus rapide que des SSDs pour notre charge de travail, ce qui est un signe manifeste de la qualité du code de journalisation. Nous utilisons du stockage sur flash pour d'autres activités.
Parallèlement à la mise à jour des serveurs, la société est passée de CentOS 5 à 6. Barker nous a dit "Une des raison de rester avec CentOS (par opposition à une distribution comme Fedora Core) est que c'est une des plateformes supportées par Azul Zing". Actuellement, LMAX Exchange utilise Oracle Hotspot en production.
Les serveurs sont situés dans un datacenter d'Equinix à l'ouest de Londres, là où un grand nombre d'autres sociétés de services financiers ont aussi leurs serveurs et applications, donc la latence entre les systèmes est comparativement faible. La société a aussi un datacenter de secours (_Disaster Recovery_) au centre de Londres et un troisième site au nord de Londres qui héberge les serveurs de tests et de développement avec un service d'intégration continue basé sur Jenkins utilisant un cloud privé OpenStack. "Nous utilisons aussi largement les services cloud d'Amazon et de Rackspace", Barker nous dit-il, "pour des systèmes qui ne contiennent pas de données de clients et ne sont pas sensibles à la latence."
La société gère en moyenne 1000 à 2000 ordres par seconde avec des pics à plus de 5000. En de rares occasions, elle est passé à plus de 20000 ordres par seconde. "Nous testons en utilisant notre pic de charge comme la valeur soutenue de référence, et nous lançons régulièrement des tests pour trouver le point de rupture du système (appelés des tests 'Red Line')."
LMAX Exchange publie des données sur ses performances ; la latence d'un ordre est 1.5ms en moyenne, alors que la latence de trading est moins de 3ms de bout en bout, incluant des contrôles de risque préliminaires.
Bien que ces chiffres soient impressionnants, les variations causées principalement par le garbage collector CMS d'HotSpot, deviennent un problème important. LMAX Exchange a essayé d'utiliser la version de CMS du JDK 7, mais a fait face à une augmentation d'environ 20% de la durée des pauses du GC pour la même charge. Les causes ne sont pas entièrement définies, mais Barker a suggéré qu'il y a un besoin de re-tuner le GC. Le fait que le garbage collector de Zing (C4) ne requiert typiquement que peu ou pas de tuning a été un argument majeur pour LMAX Exchange.
Je pense que nous avions vraiment besoin de re-régler les paramètres du GC et d'investiguer si les nouvelles options du JDK7 comme -XX:+UseCondCardMark et -XX:+UseNUMA devaient être utilisées. Une des autres grandes raisons d'utiliser Azul est la diminution du besoin de tuner le GC. Les recommandations générales sont que vous devriez re-tuner à partir du départ pour chaque nouvelle version du JDK, ce qui semble une bonne idée en théorie, mais peut être irréalisable en pratique. Le tuning du GC dans le JDK d'Oracle consiste essentiellement en le parcours d'un grand espace de recherche pour trouver un résultat qui répond à vos besoins. L'expérience, la connaissance et des suppositions peuvent éliminer des zones de cet espace de recherche, mais même comme ça, un vaste exercice de tuning peut prendre des semaines. Par exemple, notre test de performance de bout en bout prend une heure (10 minutes de build et déploiement, 10 minutes de warm-up, 40 minutes de test), donc je peux raisonnablement effectuer 8 runs par jour. Si vous considérez le nombre de différents GC (CMS, Parallel, Serial,...) et toutes les options associées (taille des new et old generation, survivor spaces, survivor ratios,...), combien de runs dois-je effectuer pour avoir une couverture efficace de cet espace : 20, 30, plus ? Les paramètres par défaut de Zing marchent significativement mieux qu'un JDK Oracle bien réglé. Nous avons encore quelques investigations pour voir si nous pouvons obtenir un peu plus de performance de la VM Zing avec du tuning (e.g. moins de thread de collection puisque notre rythme d'allocation est relativement faible). Cependant, tuner Zing est simplement ça, i.e. chercher à tirer le meilleur du système ; à comparer au JDK d'Oracle où le tuning fait la différence entre utilisable et inutilisable. L'effort nécessaire pour le tuning s'accompagne d'un coût d'opportunité. Je préférerai voir les développeurs qui seraient typiquement impliqués dans le tuning du GC (ce sont probablement ceux qui ont la meilleure expérience en performance logicielle) travailler sur l'amélioration des performances d'autres parties du système.
Une autre option serait d'évaluer deux autres GC, le Balanced GC d'IBM et le G1 d'Oracle. Bien qu'ils aient été développés indépendemment ils semblent remarquablement similaires, et visent à atteindre des durée de pauses courtes et stables. Ils utilisent la compaction incrémentale, une technique qui suppose que certaines région de la mémoire sont plus populaires que d'autres, permettant au GC de compacter une seule région à la fois et de seulement scanner les régions pointant vers celle ci pour remapper les références. Cette hypothèse peut être vrai pour la majorité des applications, mais elle n'est pas universellement vrai. De plus, alors que tous les GC ont une phase de marquage principalement concurrente, et une phase de compaction principalement incrémentale pour la old generation, ils ont aussi un fall-back vers un GC stop-the-world. Finalement, comme tous les autres GC commerciaux excepté le C4 d'Azul, ils utilisent un GC non concurrent et stop-the-world pour la young generation. Par comparaison, le C4 d'Azul utilise le même algorithme entièrement concurrent et compactant pour la young et la old generation, sans fall-back. Un article précédent d'InfoQ a exploré l'algorithme plus en détail.
Étant donné cela, LMAX Exchange n'a essayé ni G1 ni Balanced GC. Barker : "Tous deux souffrent encore du même problème fondamental que CMS, bien qu'ils puissent retarder les pauses potentielles, ils ne les éradiquent pas complètement." Donc :
...des implémentations de GC disponibles sur le marché, les seules autres options qui semblent possibles sont Metronome d'IBM et le Real Time collector de JRockit . Metronome est intéressant et j'aurais aimé passé du temps à l'évaluer, cependant j'ai été confronté à certaines problèmes et je n'ai pas pu le tester dans le temps que j'avais. Pour la défense d'IBM - nous poussons certaines fonctionnalité du JDK qui ne sont pas utilisées par la plupart des applications dans leurs derniers retranchements et mes rapports ont été transmis aux bonnes personnes et les problèmes ont été corrigés rapidement. Pour JRockit Real Time, malheureusement, Oracle ne continue pas son développement et il n'ira pas au delà du JDK 1.6, qui nous à paru être une impasse technologique.
Azul Zing a été celle qui marchait et montré des résultats positifs, ceci et le fait que l'équipe d'Azul étaient ravi de travailler avec nous pour améliorer le produit pour notre cas pratique, m'a convaincu.
Les résultats que LMAX Exchange constate sont remarquables : une amélioration de 10 à 20% de la latence moyenne, atteignant environ 50% au 99ème percentile. De plus,
Au 99.99ème percentile avec HotSpot, les nombres deviennent fous donc il est difficile de produire une comparaison relative, excepté dire que les valeurs de Zing sont beaucoup plus stables. Un mauvais run avec HotSpot peut facilement être un ordre de magnitude en dessous.
En terme de débit
Zing nous donne la possibilité d'élever ce que nous appelons notre "red-line" - la valeur de débit à laquelle la latence commence à exploser. Cet effet se manifeste comme un effet secondaire des pauses du GC. Si nous avons une pause qui est suffisamment longue, nous allons commencer à dropper les paquets. Le processus de ré-émission de paquets peut créer une pression contraire à travers le reste du système, amenant à des latences crevant le plafond. Avoir un GC plus efficace avec des pauses très courtes et prédictibles devrait nous permettre d'augmenter notre "red-line".
Barker signale qu'il y a beaucoup d'autres problèmes qui peuvent contribuer à la variabilité de la performance - quelques exemples sont du mauvais code, l'OS, la contentions sur des locks, et le manque de bande passante entre LMAX Exchange et ses clients. "Néanmoins, le GC était au sommet de notre liste et comme pour de nombreux exercices de tuning vous commencez par le plus grand coupable."
Azul a été témoin d'une bonne adoption parmi les services financier de Zing. En effet, le CTO d'Azul Gil Tene a dit à InfoQ que tandis que LMAX Exchange est célèbre pour leur excellence technique et performance de premier plan, ce n'est pas le plus agressif client dans le domaine de la basse latence d'Azul - "Nous en avons plusieurs qui sont plus grand, plus exigeants pour les latences (e.g. les limites de latences dans le trading d'Equities tendent à êtres plus critiques qu'elles ne le sont dans le FX)."
Une des raisons pour laquelle Zing est si attractive pour ces sociétés est qu'elle reste le seul GC qui élimine aussi bien les pauses stop-the-world de la young generation que de la old generation. Alors que les pauses de la young sont plus courtes, quand une application est particulièrement exigeante en matière de performance, elles comptent toujours. En conséquence, Tene nous dit, "Tout ce que nous avons à faire est de pointer les pauses de la newgen des autres JVMs et dire 'Celles-ci aussi vont disparaître'".
...De plus, le fait qu'il puisse gérer des taux d'allocation de plusieurs Go/sec sans détériorer les latences ou les pauses, le rend très tentant pour les développeurs qui ont travaillé dur pour ne pas allouer parce que "ça fait mal". Avec Zing, vous pouvez utiliser beaucoup de mémoire pour aller vite plutôt que d'essayer d'éviter de l'utiliser pour que ça ne fasse ni mal ni n'introduise de variabilité.
Pour une utilisation en production, Zing est facturé comme un abonnement annuel par serveur. Sans surprise, la société est réticente à révéler les informations sur les prix, mais il est du même ordre de grandeur que les JVM supportées par Oracle ou IBM.
Zing est un logiciel propriétaire mais est disponible gratuitement pour les développeurs open-source, donc vous pouvez l'essayer pendant le développement.