Le blog de Fabien DUMINY

Un blog utilisant WordPress

Skip to: Content | Sidebar | Footer

Devoxx France 2013 – NIO, pas si simple ?

21 mai, 2013 (09:00) | Devoxx France 2013, Java | By: fabien

A l’occasion de Devoxx France 2013, j’ai assisté à la conférence intitulée « NIO, pas si simple ? » présentée par Emmanuel Lecharny.

Rappel des différentes API d’entrées/sorties en Java

  • BIO (Blocking IO)

    Cette API, présente depuis le début de Java, permet la programmation classique d’entrées/sorties bloquantes, comme en langage C.

    Elle est plus performante que les 2 autres API. Chaque opération bloque un thread. Il faut donc l’utiliser quand il y a peu de connections simultanées (chaque connexion dispose de son thread dédié), c’est à dire 10000 au maximum.
  • NIO (New I/O)

    Cette API, apparue avec le jdk 1.4, est plus complexe à utiliser. Il faut d’abord appeler l’une des méthodes select (select() ou select(long)), ce qui bloque le thread appelant en attente d’une opération possible (accept, connect, read, write) sur l’un des sélecteurs. Ensuite, on exécute l’opération pour laquelle chaque sélecteur est prêt.

    Avec cette API, un thread est réveillé quand une donnée est reçue. Elle fonctionne sur un mode événementiel et il faut donc moins de threads que de connections. Elle ne sert pas à règler les problèmes de charge et est environ 20 à 30% moins rapide que BIO.

  • AIO (Async IO) ou NIO2

    C’est la deuxième version de NIO, apparue dans le jdk 7. Dans cette version, le système d’exploitation gère le select. NIO2 un peu plus rapide que NIO, de l’ordre de 2 à 3%.

Pour un mode non connecté, il faut utiliser BIO. Pour un mode connecté avec beaucoup de connections, il faut utiliser NIO. Quand à l’API AIO (NIO2), il est préférable de l’éviter car elle apporte un gain minime par rapport à NIO, au prix d’une utilisation importante de la mémoire.

Le framework Apache Mina

Celui-ci constitue une alternative au projet Netty et fournit une API de haut niveau afin de masquer les API bas niveau d’entrées/sorties en Java. Actuellement, l’implémentation est basée sur NIO mais les futures versions permettront de choisir entre BIO, NIO et AIO (NIO2).

L’écriture d’un serveur de type « echo » nécessite seulement 6 lignes de code.

Mina fonctionne suivant 2 protocoles : TCP et UDP.

  • Mode TCP

    Une nouvelle session est créée lors du bind.
    En lecture/écriture, on reçoit/envoit des fragments de message dans le désordre.
  • Mode UDP

    Une nouvelle session est créée lors du premier message d’un client identifié par son adresse IP.
    Ce mode est sans état par défaut mais il est possible de gérer un état.
    En lecture/écriture, on reçoit/envoit un message complet ou rien (mais on ne le sait pas).

Mina est architecturé sur un modèle événementiel :

  • exception capturée
  • message reçu
  • message envoyé : les envois sont mémorisés tant que le client ne lit pas ses messages, ce qui peut conduire à un accroissement de l’utilisation de la mémoire
  • session fermée
  • session créée
  • session inactive : on distingue l’inactivité en lecture, en écriture ou les 2
  • session ouverte

Au niveau paramétrage, Mina permet de rajouter des filtres pour traiter les messages, des encodeurs/décodeurs et de spécifier un Executor.

On trouve des encodeurs/décodeurs pour les messages à taille fixe, avec délimiteur (retour chariot ou autre caractère), les messages avec couples longueur/valeur. Il est possible d’en écrire d’autres en faisant attention qu’ils soient sans état car ils sont partagés entre plusieurs threads. Si on souhaite mémoriser un état, il faut utiliser la session.

Pour terminer, Emmanuel nous indique que le goulot d’étranglement est rarement au niveau du réseau ethernet mais plus souvent au niveau des accès disque (car ceux-ci sont nettement plus lents).

Be Sociable, Share!
Share and Enjoy

Write a comment





If your website is claim enabled, it will be notified that you have posted here.

MySQL query error