Netty contre Apache MINA


144

Ils offrent tous deux à peu près les mêmes fonctionnalités. Lequel dois-je choisir pour développer mon serveur TCP hautes performances? Quels sont les avantages et les inconvénients?

Liens de référence:

Apache MINA ( source )

Netty ( source )


6
Serait également intéressant d'ajouter Grizzly à la comparaison.
Mark

Grizzly est une bête complètement différente. Il y avait même l'idée du soutien de Grizzly au MINA, lorsque les deux groupes se sont entretenus.
codé en dur

1
@Hardcoded vous dites que le grizzly est une bête complètement différente, je suis un nouveau venu dans ce domaine, pouvez-vous s'il vous plaît souligner les différences ou me donner un article à lire à ce sujet? J'apprécierais vraiment.
arg20

1
Grizzly a un arrière-plan différent et la dernière fois que je l'ai regardé, il était principalement adapté aux applications basées sur HTTP. Je viens de regarder les exemples et j'ai été surpris de voir qu'ils utilisent une structure très similaire à celle de MINA ou Netty. Donc, la bête n'est plus si différente
codé en dur

Réponses:


211

Bien que MINA et Netty aient des ambitions similaires, elles sont assez différentes dans la pratique et vous devez réfléchir attentivement à votre choix. Nous avons eu la chance d'avoir beaucoup d'expérience avec MINA et d'avoir eu le temps de jouer avec Netty. Nous avons particulièrement aimé l'API plus propre et une bien meilleure documentation. Les performances semblaient meilleures sur le papier aussi. Plus important encore, nous savions que Trustin Lee serait sur place pour répondre à toutes nos questions, et il l'a certainement fait.

Nous avons trouvé tout plus facile à Netty. Période. Alors que nous essayions de réimplémenter les mêmes fonctionnalités que nous avions déjà sur MINA, nous l'avons fait à partir de zéro. En suivant l'excellente documentation et les exemples, nous nous sommes retrouvés avec plus de fonctionnalités dans beaucoup, beaucoup moins de code.

Le pipeline Netty fonctionnait mieux pour nous. C'est en quelque sorte plus simple que MINA, où tout est un gestionnaire et c'est à vous de décider s'il faut gérer les événements en amont, les événements en aval, les deux ou consommer plus de choses de bas niveau. Avaler des octets dans les décodeurs "rejouants" était presque un plaisir. C'était également très agréable de pouvoir reconfigurer le pipeline à la volée si facilement.

Mais l'attraction vedette de Netty, à mon humble avis, est la possibilité de créer des gestionnaires de pipeline avec une "couverture d'un". Vous avez probablement déjà lu cette annotation de couverture dans la documentation, mais elle vous donne essentiellement un état dans une seule ligne de code. Sans déconner, sans mappage de session, synchronisation et autres choses comme ça, nous avons simplement pu déclarer des variables régulières (par exemple, "nom d'utilisateur") et les utiliser.

Mais ensuite, nous avons frappé un barrage routier. Nous avions déjà un serveur multi-protocoles sous MINA, dans lequel notre protocole d'application fonctionnait sur TCP / IP, HTTP et UDP. Lorsque nous sommes passés à Netty, nous avons ajouté SSL et HTTPS à la liste en quelques minutes! Jusqu'ici tout va bien, mais en ce qui concerne UDP, nous avons réalisé que nous avions dérapé. MINA était très gentil avec nous en ce sens que nous pouvions traiter UDP comme un protocole «connecté». Sous Netty, une telle abstraction n'existe pas. UDP est sans connexion et Netty le traite comme tel. Netty expose davantage la nature sans connexion d'UDP à un niveau inférieur à celui de MINA. Il y a des choses que vous pouvez faire avec UDP sous Netty que vous ne pouvez faire avec l'abstraction de niveau supérieur fournie par MINA, mais sur lesquelles nous nous sommes appuyés.

Il n'est pas si simple d'ajouter un wrapper "UDP connecté" ou quelque chose. Compte tenu des contraintes de temps et sur les conseils de Trustin que la meilleure façon de procéder était de mettre en place notre propre fournisseur de transport à Netty, ce qui ne serait pas rapide, nous avons dû abandonner Netty à la fin.

Alors, regardez attentivement les différences entre eux et arrivez rapidement à un stade où vous pouvez tester toute fonctionnalité délicate fonctionne comme prévu. Si vous êtes convaincu que Netty fera le travail, alors je n'hésiterais pas à aller avec MINA. Si vous passez de MINA à Netty, la même chose s'applique, mais il convient de noter que les deux API sont vraiment très différentes et que vous devriez envisager une réécriture virtuelle pour Netty - vous ne le regretterez pas!


3
re: commentaire précédent de Josh sur le manque de support pour UDP dans Netty: Je ne comprends pas pourquoi vous ne pouviez pas utiliser quelques pages de code artisanal pour faire ce dont vous avez besoin, plutôt que d'abandonner Netty. UDP écoute de toute façon sur un port différent. J'ai testé Netty vs Nginx et je suis assez impressionné (Netty obtient à peu près le même score, ou mieux, sous charge).

137

MINA a plus de fonctionnalités prêtes à l'emploi au prix de la complexité et des performances relativement médiocres. Certaines de ces fonctionnalités ont été intégrées dans le noyau trop étroitement pour être supprimées même si elles ne sont pas nécessaires à un utilisateur. Dans Netty, j'ai essayé de résoudre ces problèmes de conception tout en conservant les atouts connus de MINA.

Actuellement, la plupart des fonctionnalités disponibles dans MINA sont également disponibles dans Netty. À mon avis, Netty a une API plus propre et plus documentée puisque Netty est le résultat d'une tentative de reconstruction de MINA à partir de zéro et de résoudre les problèmes connus. Si vous constatez qu'une fonctionnalité essentielle manque, n'hésitez pas à publier votre suggestion sur le forum. Je serais heureux de répondre à votre préoccupation.

Il est également important de noter que Netty a un cycle de développement plus rapide. Vérifiez simplement la date de sortie des versions récentes. En outre, vous devez considérer que l'équipe MINA procédera à une réécriture majeure, MINA 3, ce qui signifie qu'elle rompra complètement la compatibilité de l'API.


21
Oh, @trustin est l'auteur de MINA et de Netty.
Jason Heo

@trustin, j'ai trouvé que Netty 5.0 ne fournit pas beaucoup de documents avancés et que le contenu Web actuel avec une autre version ne fonctionnerait pas. avez-vous un lien de recommandation pour un tutoriel mina intermédiaire et avancé? merci
Korben

22

J'ai testé les performances de 2 implémentations "Google Protobuffer RPC" où l'une était basée sur Netty (netty-protobuf-rpc) et l'autre basée sur mina (protobuf-mina-rpc). Netty a fini par être constamment plus rapide (+ - 10%) pour toutes les tailles de message - ce qui confirme la performance globale sur le site Web de Netty. Puisque vous voulez tirer le maximum d'efficacité de votre code lorsque vous utilisez une telle bibliothèque RPC, j'ai fini par écrire protobuf-rpc-pro basé sur Netty. J'ai utilisé MINA dans le passé, mais je trouve que leur documentation sur les éléments 2.0 comporte de gros trous et que la rupture de la compatibilité descendante des API est un gros inconvénient.


16

MINA et Netty ont été initialement conçus et construits par le même auteur. C'est pourquoi ils sont si similaires les uns aux autres. MINA est conçu à un niveau légèrement supérieur avec un peu plus de fonctionnalités, tandis que Netty est un peu plus rapide. Je pense qu'il n'y a pas du tout de différence, les concepts de base sont les mêmes.


9

Sur le site Netty, vous pouvez trouver des rapports de performance . Comme prévu :-) ils indiquent Netty comme le framework avec les meilleures performances.

Je n'ai jamais utilisé Netty, mais j'ai déjà utilisé MINA pour implémenter un protocole TCP. La mise en œuvre de l'encodage et du décodage était facile, mais la mise en œuvre de la machine à états n'était pas si facile. MINA fournit quelques classes pour vous aider lors de l'implémentation de la machine d'état, mais je les ai trouvées assez difficiles à utiliser. En fin de compte, nous avons décidé d'abandonner MINA et d'implémenter le protocole à partir de zéro, et étonnamment, nous avons terminé avec un serveur plus rapide.


5

Je préfère Netty.

Twitter a également choisi Netty pour créer son nouveau système de recherche et l'a accéléré jusqu'à 3 fois plus vite.

Réf: la recherche sur Twitter est maintenant 3 fois plus rapide

Nous avons choisi Netty plutôt que certains de ses autres concurrents, comme Mina et Jetty, car il dispose d'une API plus propre, d'une meilleure documentation et, plus important encore, parce que plusieurs autres projets sur Twitter utilisent ce framework.


4

Je n'ai jamais utilisé MINA que pour créer un petit serveur de type http. Les plus gros problèmes que j'ai rencontrés avec lui jusqu'à présent:

  1. Il conservera votre "demande" et "réponse" en mémoire. Ce n'est qu'un problème car le protocole que je choisis d'utiliser est http. Vous pouvez cependant utiliser votre propre protocole pour contourner ce problème.
  2. Aucune option pour fournir un flux hors disque au cas où vous voudriez servir de gros fichiers. Encore une fois peut être contourné en implémentant votre propre protocole

Belles choses à ce sujet:

  1. Peut gérer de nombreuses connexions
  2. Si vous choisissez de mettre en œuvre une sorte de système de travail distribué, il est utile de savoir quand l'un de vos nœuds tombe en panne et perd la connexion pour redémarrer le travail sur un autre nœud.

Lorsque vous dites "diffuser hors disque pour les gros fichiers", les gens n'utilisent-ils pas normalement UDP pour cela?
djangofan

1
Non. Ils utilisent le noyau sendfile (exposé en Java sous le nom FileChannel.transferTo) sur TCP.
jbellis
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.