Discussion :

[jeje99]

Bonjour,

Je surfais sur le forum, et je tombe sur quelqu'un qui cherche à optimiser son serveur Java.

A la fin du topic, on l'oriente vers une solution utilisant une lib d'apache appelé Mina. Actuellement, je travaille justement sur du développement de server en Java, je me jette donc sur le lien vers le site d'appache (http://directory.apache.org/subprojects/network/). J'ai donc commencer à regarde commant cette API fonctionne...

J'ai bien compris que ça permettait de faciliter grandement la création d'un serveur, mais je n'ai pas compris en quoi cette API était plus performante comparée à un serveur à base de thread et d'écoute sur les socket ?

Y a t'il quelque personne qui pourrait éclairer ma lanterne ?

[nic58]

Salut,

Tu peux déjà regarder par ici (fr) et par là (en) pour savoir pourquoi un serveur basé sur java.nio est plus performant.

Bon courage.
Personnellement, je trouve Mina très pratique.

[Pill_S]

Hello,

Y a t'il quelque personne qui pourrait éclairer ma lanterne ?

je peux essayer...

lorsque tu fais un serveur, tu as en général 1 thread par client connecté... si ton serveur doit gérer 5000 clients simultanés, cela fait 5000 threads qui tournent +/- en même temps... Lorsqu'un thread laisse la main à un de ses congénères, le système doit rétablir le "contexte" du thread qui reprend la main... ce qui prend un temps important... et avec 5000 threads, le système ne fait pratiquement plus que ça, ce qui laisse peu de temps pour le "vrai" travail...

Avec java.nio (ou Mina), un seul thread s'occupe de tous les clients...

vois ça comme un standardiste téléphonique, qui gère plusieurs appels en même temps... dès qu'un appel arrive sur sa station, et si le standardiste est libre, il effectuera son travail... si plusieurs appels arrivent en même temps, le standardiste va les traiter les uns après les autres...

en résumé:
- la vieille méthode, c'est de mettre un standardiste (thread) par ligne téléphonique (client)
- la nouvelle méthode, c'est de mettre un standardiste pour toutes les lignes téléphoniques de l'entreprise... ça coûte moins cher

[jeje99]

Mmm si je comprend bien (dites moi si j'ai bien compris). Le problème de performance est lié à la machine virtuelle, les traitements multitaches sont trop lourd pour une gestion de socket.

La solution a donc été de faire une sorte d'ordonnanceur dédié à l'échange de flux donc plus optimisé, j'ai bon ?

Si j'ai bien compris aussi, dans cette api, on utilise un nouveau type de donnée pour les échanges : la classe Buffer à la place des inputStream, outputStream ou autre Reader ou Writer.

Autre question, est - ce que cette api, implémente une surcouche de protocole au dessus d'une socket TCP. Par exemple, si j'upgrade un serveur vers java.nio. Aurais je besoin de modifier les clients existants programmés en d'autre langage (vb, c, c++, pyton) ?

Sinon, quelqu'un a t'il des benchmarchs sérieux sur les performances de cette api ?

[Pill_S]

Hello,

Mmm si je comprend bien (dites moi si j'ai bien compris). Le problème de performance est lié à la machine virtuelle, les traitements multitaches sont trop lourd pour une gestion de socket.

c'est plutôt lié au fait que le multithread est gourmand en ressources. Les socket sont aussi utilisés avec java.nio (classe Socket), mais de manière indirecte (avec les Selector et les SelectionKey), et surtout non bloquant: si tu fais un "read" sur un socket standard, cela bloque le thread courant jusqu'à réception de données.
avec java.nio, le read est indirect, lorsque la méthode "aSelectionKey.isReadable()" renvoie true cela signifie que des données sont disponibles immédiatement en lecture (contenues dans le buffer de la socket)

La solution a donc été de faire une sorte d'ordonnanceur dédié à l'échange de flux donc plus optimisé, j'ai bon ?

vi, c'est ça

Si j'ai bien compris aussi, dans cette api, on utilise un nouveau type de donnée pour les échanges : la classe Buffer à la place des inputStream, outputStream ou autre Reader ou Writer.

non, pas du tout
les Buffer sont là pour simplifier la vie... avec java.nio, tu ne fais qu'envoyer des tableaux de byte, et ByteBuffer est une sorte de liste de byte que l'on peut convertir en tableau. Mais tu pourrais très bien t'en passer. En arrière-plan, les données sont aussi envoyées par des InputStream/OutputStream

Autre question, est - ce que cette api, implémente une surcouche de protocole au dessus d'une socket TCP. Par exemple, si j'upgrade un serveur vers java.nio. Aurais je besoin de modifier les clients existants programmés en d'autre langage (vb, c, c++, pyton) ?

selon moi, je dirais non. il ne s'agit que d'une manière différente de gérer les clients, mais les données que tu envoies restent sous ton contrôle... enfin, faut voir

Sinon, quelqu'un a t'il des benchmarchs sérieux sur les performances de cette api ?

c'est pas vraiment un bench, mais plutôt un comparatif:
http://www.projectomega.org/article.php?lg=fr&php=oreilly_nio1&p=3

Développer un routeur complètement fonctionnel basé sur le multiplexage d'E/S ne fut pas simple. Cela nous a pris trois mois pour obtenir la bonne architecture. Une partie de ce temps nous a permis d'apprendre un nouveau modèle d'E/S peu familier. L'autre partie fut passé à comprendre la complexité qui en découlait. Enfin, nous étions assez contents du résultat. Avec nos benchmarks, le routeur était capable de traiter 10 000 clients sans perte significative de débit. Par comparaison, nous avons implémenté une version basée sur le modèle un-thread-par-client, qui ne pouvait pas servir 3 000 clients, avec une chute significative du débit au fur et à mesure de l'augmentation du nombre de clients.

[jeje99]

Merci bien pour toutes ces informations, ça à le mérite d'être clair !

Un petit résolu et zoup c'est parti pour le développement à l'aide de java.nio ...