Discussion :

[_skip]

Bonjour,
Je suis à la recherche d'avis ou retours d'expérience sur les approches "modernes" dans le développement d'applications web. On voit émerger pas mal de solutions qui s'éloignent de l'approche "Servlets" soit généralement 1 socket servi par 1 thread en mode bloquant pour se diriger vers des architectures asynchrones construites autour d'un modèle évenementiel...

Je cite entre autres parmi les noms qu'on entend : vert.x, ratpack, ou plus généralement netty sur laquelle les 2 précédents s'appuient. Je me suis intéressé à vert.x principalement, les arguments avancés par cette solutions sont assez séduisants, moins de threads nécessaires, d'où moins de ressources consommées, moins de changement de contexte et par conséquent un plus grand nombre de connexions clientes servies et une meilleure scalabilité. La gestion de la concurrence se trouve simplifiée car au lieu d'avoir un grand nombre de threads qui exécutent simultanément le même code (typiquement la même servlet), on a ici un petit nombre de threads qui exécutent le code en isolation les uns les autres, garantissant même que cette portion de code (ici appelée verticle) n'est exécutée que par un seul thread à la fois et mieux encore, toujours le même! En sommes, un petit nombre de threads dont le nombre correspondrait au nombre de coeurs) isolés les uns des autres pour gérer les requêtes sur le serveurs.

Cependant, lorsqu'on lit la documentation, on se rend compte que le rêve d'un monde merveilleux et sans compromis s'effrite quelque peu dès qu'il est question de réaliser des opérations bloquantes sur lesquels les threads doivent attendre, en gros : interdiction formelle de bloquer un verticle! Parmi les opérations bloquantes qu'on peut avoir côté serveur, la palette est plutôt large: la majorité de ce qui est opération sur les Streams, fichiers, sockets, mais aussi inévitablement tout ce qui est JDBC . On peut facilement le comprendre, si vous n'avez que 4 threads et que les 4 attendent sur le retour d'une requête vers une base de donnée, votre serveur est bloqué!

J'ai passé la matinée à chercher comment on devait s'y prendre pour créer une application orientée données type à l'aide de vert.x. Il est bien question d'un type de verticles spécial destiné aux longues opérations et à l'utilisation d'API bloquante :
http://vertx.io/manual.html#worker-verticles

Mais de façon surprenante, l'approche n'est pas très détaillée et assez peu reprise sur le net. Je suis tombé sur des dizaines d'articles de blog vantant les mérites de cette plateforme, son aspect polyglotte, son modèle d'évènement si élégant etc... mais extrêmement peu d'informations concrètes au final sur la façon de créer une application reposant fortement sur des IO? Pourtant, je pense pas que la majorité des applications web en java soient des web chats ou des services stateless qui se contentent de servir des ressources uniquement en mémoire? Donc qu'est-ce qu'on fait lorsque ce n'est pas possible de se passer d'une source de données (et donc "généralement" d'opérations bloquantes)?

Est-ce que la réponse à cette question est simplement d'admettre que c'est pas fait pour ça, d'oublier tout ce bazar et d'utiliser un bon vieux conteneur de servlets? Je ne sais pas si certains ici se sont penchés sur la question?

[_skip]

Je suis un peu déçu de pas avoir pu démarrer de discussion sur ce sujet.
Ce n'était pas vraiment le bon forum?

[Nico02]

Salut,

J'imagine simplement que ce n'est tout simplement pas une techo qui soit beaucoup utilisé par les membres de ce forum. Et pour ma part, étant dans ce cas, je préfère pas dire de bêtises plutôt que de sortir des bouts de code sortis de nulle part (même si je suis aussi intéressé par des retours)

J'ai souvenir cependant que @thierryler parlait de faire un tuto sur vert.x (voir ce thread).

Peut être pourrais tu lui adresser un message directement.

Cdt.

[tchize_]

J'ai même carrément du mal personnellement à imaginer une application réelle qui n'a pas besoin de faire une opération bloquante à un moment ou à un autre. Même avec uniquement des données en mémoire, puisqu'il y aura surement à un moment donné passage dans une bloc synchronized.... De plus, j'ai aussi du mal à imaginer le gain du à l'absence de context switching, mis en balance avec les pertes dûe à un pseudo context switching, quand l'api doit de toutes façons ramener dans la stack les données du vertice suivant. Est-ce qu'il y a concrètement des mesures cas réel de ce genre de chose? Je serais prudent à plusieurs niveaux. Tout d'abord parce que, en général, on met un serveur http en front end devant tomcat / jboss / glassfish. Et que fait le serveur http? Un process par connection établie! Donc il y a déjà de nombreux threads / context switching à ce niveau. Ensuite parce que, par expérience, on trouve souvent des sociétés prêtes à démontrer les énormes gains de performance qu'elles ont obtenues en switchant vers telle ou telle api / language. Mais ce n'est jamais mis en comparaison avec les gains de performances que l'ont aurait en réécrivant le code avec les même API qu'avant. Il y a souvent confusion entre le gain dû à l'API et le gain dû au simple fait d'avoir réécrit le code. Et souvent, c'est ce dernier qui est le facteur déterminant.

[Logan Mauzaize]

Vert.x (et plus généralement les méthodes asynchrones) reposent hélas sur un principe simple : le tout asynchrone. Ce que la plupart des APIs ne supportent pas ou qui le digèrent mal.
Sinon oui, de nettes gains sont observables sur le nombre de requête parallélisable mais pas sur le temps moyen d'une requête (au contraire). Il existe une autre technique pour augmenter le nombre de client simultané : la scalabilité horizontale.
On pense souvent à la duplication de machine mais ce n'est la seule manière, on peut aussi dupliquer le processus (fork) comme le fait déjà Apache HTTPd.

A savoir également, qu'il existe des serveurs Web frontaux qui fonctionnent également en asynchrone. Et que par leur fonction (load-balancing + request-forward, peu de traitement), ils sont moins assujettis aux problèmes de l'augmentation du nombre de client à traiter (même s'ils ont une limite qui reste souvent très haute par rapport à celle d'un serveur applicatif).
Mais il est vrai que de manière générale, si on veut atteindre une certaine capacité de client simultanés, il faut que tous les noeuds de l'infrastructure (ne pas oublier les switchs et les routeurs) soient capable également de digérer le traffic. Le problème n'en sera alors que déplacer.

Pour en revenir à Vert.x, pour les APIs qui ne supportent pas l'asynchrone, il faudra nécessairement passer par un nouveau thread mais qui consommera peu car son unique fonction sera d'attendre l'IO (attention dans ce cas à bien cibler les morceaux de code qui consomment de l'IO).
Pour JDBC, il faudra cibler les méthodes "execute" et "next" (par exemple). A voir éventuellement pour synchroniser "next" avec le "fetch size".

Le problème n'étant pas nécessairement le principe mais tout l'infrastructure qu'il convient de mettre autour. L'appel de méthode est plus intuitif que de soumettre une tâche. Surtout qu'en Java, ca peut vite devenir très verbeux. Et il faut également concevoir tout un tas de framework et d'APIs qui reposent sur ces concepts.
C'est un peu la même chose qu'avec l'API Stream.

[thierryler]

Alors, l'unité de base de Vert.x est le Verticle.

Normalement les verticles sont async et il faut absolument qu'ils soient non bloquant pour que le loop ne se bloque pas.

Si tu as besoin d'une opération bloquante, du jdbc par exemple, tu dois marquer ton verticle comme étant "worker" dans ta conf json. Dans ce cas, le verticle ne sera plus issu de la loop mais d'un thread pool classique. C'est toutefois à réserver pour quand tu n'as pas le choix.

Pour le nombre de verticle, je conseille d'en mettre 2 par coeur et non un seul ;-)

[_skip]

Merci à tous, ils semblent qu'on soit tous d'accord pour dire que cet aspect non bloquant pose un certains nombres de difficulté.

@Thierryler
Merci d'avoir répondu présent. Justement si tu déclares ton verticle comme worker, donc multithreadé, est-ce que tu te retrouves pas dans la même situation grosso-modo qu'un apache avec son connecteur Nio? Je me demande si tu retires un bénéfice à passer sur du vertx si t'as l'intention de faire une bonne grosse appli type JDBC, ou si au contraire ce serait faire fausse route (ce qui pourrait expliquer que le couple vertx +JDBC soit assez peu documenté sur le net).

[thierryler]

Je confirme que ce n'est effectivement pas la bonne piste.

Si on a besoin de base, c'est mieux de l'associer avec Cassandra par exemple.