Le Projet Netty a sorti la première version de Netty 4 en juillet. Cette version apporte des améliorations significatives des performances principalement sur la diminution de l'overhead du principe de Garbage Collection. L'intégration de Netty 4 chez Twitter a permis un gain de performances par 5, mais avec quelques coûts.
Trustin Lee, fondateur du Projet Netty et ingénieur logiciel chez Twitter, écrit des frameworks d'application réseau depuis 2003. La première release publique de Netty sortait en juin 2004. La homepage du projet décrit Netty comme un "framework d'application réseau asynchrone orienté événement pour le développement rapide de protocole clients et serveurs maintenable et de haute performance".
Comme le précise Lee dans Netty 4 at Twitter: Reduced GC Overhead, Twitter utilise Netty à plusieurs endroits pour implémenter des fonctionnalités réseaux.
Finagle est notre système de protocole RPC agnostique dont la couche de transport est construite sur Netty. Il est utilisé pour implémenter la plupart des services internes comme le Search
TFE (Twitter Front End) est notre solution propriétaire de reverse proxy pour le spoon-feeding qui gère la plupart du trafic HTTP frontal et celui de SPDY en utilisant Netty
Cloudhopper envoie des milliards de messages SMS chaque mois à des centaines d'opérateurs mobiles dans le monde entier en utilisant Netty
Netty intègre une implémentation du pattern reactor et est également au coeur du framework Play. Play, Grails et plusieurs autres frameworks Web sont en train d'adopter le pattern des Web applications WAR-less qui permet une intégration plus fine avec le serveur HTTP sous-jacent. L'utilisation d'un serveur intégré comme Netty simplifie la programmation asynchrone. La programmation asynchrone et les entrées sorties non bloquantes sont au coeur du Manifeste Réactif. InfoQ a écrit au sujet de ce pattern émergent l'article Reactive Programming as an Emerging Trend.
Netty 3 utilisait les objets Java pour représenter les événements entrée/sortie. Lee remarque que :
C'était simple mais cela pouvait générer beaucoup de garbage spécialement à notre échelle. Dans la nouvelle release de Netty 4, des changements ont été faits pour que, au lieu d'utiliser des objets événements de courte durée, les méthodes sur des objets channel de longue durée soient utilisées pour gérer les événements entrée/sortie. Il y a aussi un allocateur de buffer spécialisé qui utilise les pools.
...Netty 3 crée une nouvelle mémoire tampon chaque fois qu'un nouveau message est reçu ou si un utilisateur envoie un message à un poste distant. Cela signifie l'instruction 'new byte[capacity]' pour chaque nouveau buffer. Ces buffers causaient de la pression sur le GC et consommaient de la bande passante : allouer un nouveau tableau d'octets consomme de la bande passante mémoire pour remplir par sécurité le tableau avec des zéros. Toutefois, le tableau d'octets rempli de zéros a de fortes chances d'être rempli avec des données réelles, en consommant la même quantité de bande passante mémoire. Nous aurions pu réduire la consommation de la bande passante mémoire de 50% si la Machine Virtuelle Java (JVM) fournissait une manière de créer un nouveau tableau d'octets qui ne soit pas nécessairement rempli avec des zéros, mais il n'y a pas ce type de solutions pour le moment.
Avec Netty 4, le code définit une API plus fine qui gère les différents types d'événements plutôt que de créer ces objets événements. Il dispose également d'une nouvelle implémentation de pool de buffer, qui est une version pure Java de jemalloc (également utilisée chez Facebook). Maintenant il ne gaspille pas de la bande passante mémoire en remplissant les buffers avec des zéros. Cependant, comme il ne repose pas sur le GC ; vous devez faire attention aux fuites. Si un handler oublie de libérer un buffer, la mémoire peut augmenter indéfiniment.
Ces changements ne sont pas rétro-compatibles avec Netty 3, mais c'est 5 fois plus rapide à produire et nettoyer le garbage.
Lee écrit :
Nous avons comparé deux protocoles serveurs echo élaborés respectivement sur Netty 3 et 4. (Echo est suffisamment simple pour que tout garbage créé soit de la faute de Netty et non pas du protocole). Je leur ai donné les mêmes clients de protocole echo distribué avec 16 384 connexions simultanées envoyant répétitivement une charge aléatoire de 256 octets, presque en saturant le Gigabit ethernet.
Selon le résultat de notre test, Netty 4 a obtenu :
- Cinq fois moins de fréquence de pauses GC : 45.5 contre 9.2 times/min
- Cinq fois moins de production de Garbage : 207.11 contre 41.81 MiB/s
Lee mentionne qu'il y a certains freins à l'adoption de Netty 4 chez Twitter, comme les fuites de buffer et un noyau complexe. Le projet espère ajouter plus de fonctionnalités, incluant HTTP/2, la résolution asynchrone du DNS et du support pour les proxys HTTP et SOCKS côté client.
L'ingénierie de Yahoo décrit dans un article similaire comment Netty les a aidés à doubler la vitesse de leurs clusters Storm. Dans Making Storm fly with Netty, Bobby Evans écrit :
Chez Yahoo, nous avons l'habitude d'utiliser nos propres produits mais avant que Netty soit notre couche par défaut pour le messaging de nos clusters Storm, j'avais besoin de chiffres pour le comparer avec zeromq, qui est notre solution actuelle par défaut. Pour faire cela j'avais besoin d'un benchmark qui pouvait faire renoncer la couche de messaging de Storm, j'en ai ainsi écrit un. C'est un simple test de vitesse pure qui montre la rapidité avec laquelle Storm peut envoyer des messages entre les bolts et les spouts. Il nous permet de lancer plusieurs topologies de complexités variables qui envoient des messages de taille fixe.
Evans montre qu'avec un petit test (sans immobilisation de ressource), Netty est beaucoup plus rapide (40 à 100%) que zeromq. Avec un test plus important, il se heurte à des problèmes de performance, mais la diminution du nombre de threads permet de résoudre le problème.
La configuration par défaut de Netty n'est pas terrible pour traiter beaucoup de petits messages même quand il est seul sur le noeud. Mais lorsqu'on le limite à un seul thread nous sommes capables d'obtenir entre 111% et 85% de messages en plus par seconde que zeromq, et ensuite le réseau sature de nouveau.
Evans précise que Netty est utilisé maintenant par défaut pour les clusters Storm de Yahoo.
Les améliorations apportées dans Netty 4 seront probablement bénéfiques pour de nombreux projets open source. Le framework a une longue liste de projets connexes, comme Akka, Apache James, HornetQ et Vert.x, pour n'en nommer que quelques-uns. Pour en savoir plus sur Netty 4, aller voir netty.io ou le blog de Lee.