Un article parmi d'autres qui évoquent certains problèmes de node/js The Node.js Event Loop is a Damn Mess
Mouai aussi.
Tous les problèmes évoqués ont des solutions. Certaines sont d'ailleurs évoquées dans le texte. Oui si on surcharge un certain type d'I/O sans prendre de précautions on peut exploser l'appli. Comme dans n'importe quel autre langage.
Mais bon en JavaScript
a) On a généralement beaucoup plus de marge avant que ça ne se produise. Un script JS accepte et traite les requêtes I/O a des vitesses démentielles pour le peu de code écrit par le dev.
b) On a systématiquement une pléthore de solutions :
- Trop de petites demandes en simultané ? Ben on lance une seconde, puis une troisième instance de la même appli, que ce soit avec de la proxification (nginx par exemple) ou via le forking natif node
- Le back-end n'arrive pas à suivre ? Ben on fait du state counting quand on rentre dans les promesses/event loops problématiques et on limite le nombre de connexions au backend.
- Certaines opérations de calculs prennent trop de temps CPU et pourissent le time sharing ? Ben on les exporte dans des workers.
-Certains backend n'ont pas la politesse de nous insulter ou de nous raccrocher au nez quand ils ne peuvent pas traiter la demande ? setTimeout() et c'est réglé.
-Trop de callbacks - on utilise des promesses A+
-Trop de promesses illisibles imbriquées les unes dans les autres ? Ben scope dédié avec un event loop.
-Une instance Node bouffe trop de mémoire ? Ben on ferme la création de nouvelles sessions (on laisse ça à d'autres instances) et on fait un graceful restart.
Etc.
Et très honnêtement citer PHP comme exemple du truc à faire ? Sur les threads par session ? On parle bien du langage qui oblige à mettre des entrées dans le cron toutes les X heures pour éviter les memory leak, et qui va bazarder toute la session si un seul évènement non interceptable se pointe ? PHP qui va prendre 2000 descripteurs, des heures de debug et l'aide d'un module Apache de rewriting pour faire un routage web correct en cas de forte charge ? Sérieusement ?
JavaScript a des défauts, beaucoup même, mais malgré les très gros progrès de PHP ces dernières années - il ne tient pas une seconde la comparaison avec NodeJS + Koa/Express.
La personne qui a écrit cette article ne donne pas d'exemples concrets (juste une analogie idiote qui revient à dire que chaque scope amènerait du temps CPU avec lui à l’instanciation GNI ???) - Mais à mon sens il s'agit d'un cas typique d'un mec qui veut faire du PHP/Java/Ruby/C++ ou autre en JavaScript, et qui se plaint que ça ne marche pas.
Cette phrase en particulier
Exceeding the stack size is so common because there is no good way for the programmer to slow down the influx of operations from the execution queue while all these unreturned function calls are performing work.
Pourrait difficilement être plus fausse. J'ai rarement vu de langage qui offrait autant de méthodes simples, lisibles et maintenables pour gérer les évènements asynchrones.
[^] # Re: Opinion personnelle
Posté par Kaane . En réponse au journal Et si JavaScript allait droit dans le mur ?. Évalué à 5.
Mouai aussi.
Tous les problèmes évoqués ont des solutions. Certaines sont d'ailleurs évoquées dans le texte. Oui si on surcharge un certain type d'I/O sans prendre de précautions on peut exploser l'appli.
Comme dans n'importe quel autre langage.
Mais bon en JavaScript
a) On a généralement beaucoup plus de marge avant que ça ne se produise. Un script JS accepte et traite les requêtes I/O a des vitesses démentielles pour le peu de code écrit par le dev.
b) On a systématiquement une pléthore de solutions :
- Trop de petites demandes en simultané ? Ben on lance une seconde, puis une troisième instance de la même appli, que ce soit avec de la proxification (nginx par exemple) ou via le forking natif node
- Le back-end n'arrive pas à suivre ? Ben on fait du state counting quand on rentre dans les promesses/event loops problématiques et on limite le nombre de connexions au backend.
- Certaines opérations de calculs prennent trop de temps CPU et pourissent le time sharing ? Ben on les exporte dans des workers.
-Certains backend n'ont pas la politesse de nous insulter ou de nous raccrocher au nez quand ils ne peuvent pas traiter la demande ? setTimeout() et c'est réglé.
-Trop de callbacks - on utilise des promesses A+
-Trop de promesses illisibles imbriquées les unes dans les autres ? Ben scope dédié avec un event loop.
-Une instance Node bouffe trop de mémoire ? Ben on ferme la création de nouvelles sessions (on laisse ça à d'autres instances) et on fait un graceful restart.
Etc.
Et très honnêtement citer PHP comme exemple du truc à faire ? Sur les threads par session ? On parle bien du langage qui oblige à mettre des entrées dans le cron toutes les X heures pour éviter les memory leak, et qui va bazarder toute la session si un seul évènement non interceptable se pointe ? PHP qui va prendre 2000 descripteurs, des heures de debug et l'aide d'un module Apache de rewriting pour faire un routage web correct en cas de forte charge ? Sérieusement ?
JavaScript a des défauts, beaucoup même, mais malgré les très gros progrès de PHP ces dernières années - il ne tient pas une seconde la comparaison avec NodeJS + Koa/Express.
La personne qui a écrit cette article ne donne pas d'exemples concrets (juste une analogie idiote qui revient à dire que chaque scope amènerait du temps CPU avec lui à l’instanciation GNI ???) - Mais à mon sens il s'agit d'un cas typique d'un mec qui veut faire du PHP/Java/Ruby/C++ ou autre en JavaScript, et qui se plaint que ça ne marche pas.
Cette phrase en particulier
Pourrait difficilement être plus fausse. J'ai rarement vu de langage qui offrait autant de méthodes simples, lisibles et maintenables pour gérer les évènements asynchrones.