Qu'y a-t-il de si différent dans l'événementiel de Node.js? Ne pouvons-nous pas faire cela dans HttpAsyncHandler d'ASP.Net?
Je ne suis pas très expérimenté en programmation Web, et je n'ai encore rien codé dans Node.js, juste curieux de savoir approche événementielle . Cela semble bon.
L'article explique certaines mauvaises choses qui pourraient se produire lorsque nous utilisons une approche basée sur les threads pour gérer les demandes, et devrions plutôt opter pour une approche événementielle. En mode fil, le caissier/fil est coincé avec nous jusqu'à ce que notre nourriture/ressource soit prête. En cas d'événement, la caissière nous envoie quelque part hors de la file d'attente des demandes afin que nous ne bloquions pas les autres demandes en attendant notre nourriture. Pour mettre à l'échelle le blocage des threads, vous devez augmenter le nombre de threads. Pour moi, cela semble être une mauvaise excuse pour ne pas utiliser correctement les threads/threadpools.
Cela ne pourrait-il pas être correctement géré à l'aide de IHttpAsyncHandler? ASP.Net reçoit une demande, utilise le ThreadPool et exécute le gestionnaire (BeginProcessRequest), puis à l'intérieur, nous chargeons le fichier/base de données avec un rappel. Ce thread devrait alors être libre de gérer d'autres requêtes. Une fois la lecture du fichier terminée, le ThreadPool est à nouveau mis en action et exécute la réponse restante. Pas si différent pour moi, alors pourquoi n'est-ce pas aussi évolutif?
L'un des inconvénients des threads que je connais est que l'utilisation de threads nécessite plus de mémoire. Mais seulement avec ceux-ci, vous pouvez profiter des avantages de plusieurs cœurs. Je doute que Node.js n'utilise aucun thread/noyau.
Donc, en se basant uniquement sur l'argument événementiel par rapport au thread (n'apportez pas l'argument "parce que c'est Javascript et tous les navigateurs ..."), quelqu'un peut-il me faire remarquer quel est l'avantage réel d'utiliser Node.js au lieu de la technologie existante?
C'était une longue question. Merci :)
Tout d'abord, Node.js n'est pas multi-thread. C'est important. Vous devez être un programmeur très talentueux pour concevoir des programmes qui fonctionnent parfaitement dans un environnement fileté. Les fils sont juste durs.
Vous devez être un dieu pour maintenir un projet fileté là où il n'a pas été conçu correctement. Il y a tellement de problèmes qui peuvent être difficiles à éviter dans les très grands projets.
Deuxièmement, toute la plateforme a été conçue pour être exécutée de manière asynchrone. Avez-vous vu un projet ASP.NET où chaque interaction IO était asynchrone? Simplement, ASP.NET n'a pas été conçu pour être piloté par les événements.
Ensuite, il y a l'empreinte mémoire due au fait que nous avons un thread par connexion ouverte et tout le problème de mise à l'échelle. Corrigez-moi si je me trompe, mais je ne sais pas comment vous éviteriez de créer un nouveau thread pour chaque connexion dans ASP.NET.
Un autre problème est qu'une demande Node.js est inactive lorsqu'elle n'est pas utilisée ou en attente d'E/S. D'un autre côté, un thread C # est en veille. Maintenant, il y a une limite au nombre de ces threads qui peuvent dormir. Dans Node.js, vous pouvez facilement gérer simultanément 10 000 clients en parallèle sur une seule machine de développement. Vous essayez de gérer des threads 10k en parallèle sur une machine de développement.
JavaScript lui-même en tant que langage facilite le codage asynchrone. Si vous êtes toujours en C # 2.0, alors la syntaxe asynchrone est vraiment pénible. Beaucoup de développeurs seront tout simplement confus si vous définissez Action<> et Function<> partout et en utilisant les rappels. Un projet ASP.NET écrit de manière événementielle n'est tout simplement pas maintenable par un développeur ASP.NET moyen.
Quant aux fils et noyaux. Node.js est monothread et évolue en créant des processus à nœuds multiples. Si vous avez un cœur 16, vous exécutez 16 instances de votre serveur node.js et avez un seul équilibreur de charge Node.js devant lui. (Peut-être un équilibreur de charge nginx si vous le souhaitez).
Tout cela a été écrit dans la plateforme à un niveau très bas dès le début. Ce n'était pas une fonctionnalité boulonnée plus tard sur la ligne.
Autres avantages
Node.js a beaucoup plus que ci-dessus. Ce qui précède n'est que la raison pour laquelle la façon dont Node.js gère la boucle d'événements est meilleure que de le faire avec des capacités asynchrones dans ASP.NET.
- Performance. C'est rapide. Très vite.
- Un gros avantage de Node.js est son API de bas niveau. Vous avez beaucoup de contrôle.
- Vous avez l'intégralité du serveur HTTP intégré directement dans votre code puis sous-traité à IIS.
- Vous avez l'intégralité de la comparaison nginx vs Apache.
- L'ensemble du défi C10K est bien géré par nœud mais pas par IIS
- La communication AJAX et JSON est naturelle et facile.
- La communication en temps réel est l'un des avantages de Node.js. C'était fait pour ça.
- Joue bien avec les bases de données nosql basées sur des documents.
- Peut également exécuter un serveur TCP. Peut également accéder à l'écriture de fichiers, peut exécuter n'importe quelle commande de console Unix sur le serveur.
- Vous interrogez votre base de données en javascript en utilisant, par exemple, CouchDB et mapper/réduire. Vous écrivez votre client en JavaScript. Il n'y a pas de changement de contexte lors du développement sur votre pile Web.
- Ensemble riche de modules open source pilotés par la communauté. Tout dans node.js est open source.
- Faible encombrement et presque aucune dépendance. Vous pouvez créer vous-même la source node.js.
Inconvénients de Node.js
C'est dur. C'est jeune. En tant que développeur qualifié JavaScript, j'ai du mal à écrire un site Web avec Node.js simplement en raison de sa nature de bas niveau et du niveau de contrôle que j'ai. Cela ressemble à C. Beaucoup de flexibilité et de puissance à utiliser pour moi ou à me suspendre.
L'API n'est pas figée. Ça change rapidement. Je peux imaginer avoir à réécrire un grand site Web complètement en 5 ans à cause de la quantité de Node.js qui sera modifiée d'ici là. C'est faisable, il suffit de savoir que la maintenance sur les sites Web node.js n'est pas bon marché.
lecture supplémentaire
http://blog.mixu.net/2011/02/01/understanding-the-node-js-event-loop/
Il y a beaucoup d'idées fausses concernant node.js contre ASP.Net et la programmation asynchrone. Vous pouvez faire non bloquant IO dans ASP.NET . La plupart des gens ne savent pas que le . Le framework Net utilise les ports iocompletion de Windows en dessous lorsque vous effectuez des appels de service Web ou d'autres opérations liées aux E/S en utilisant le modèle de début/fin dans .Net 2.0 et supérieur. IO ports d'achèvement est la façon dont le système d'exploitation Windows prend en charge le non-blocage IO afin que le thread d'application soit libéré pourquoi l'opération IO se termine. Fait intéressant, node.js utilise une implémentation IO non bloquante moins optimale dans Windows via Cygwin. Une nouvelle version de Windows est sur la feuille de route qui, avec les conseils de Microsoft, utilisera les ports de fin de IO. À ce stade, il n'y a aucune différence.
Il est également possible d'effectuer des appels de base de données non bloquants dans ADO.NET, mais soyez conscient des outils ORM tels que NHibernate et Entity Framework. Ils sont toujours très synchrones.
Synchrone IO (blocage) rend le flux de contrôle beaucoup plus clair et c'est pour cette raison qu'il est devenu populaire. La raison pour laquelle les environnements informatiques sont multithread n'a que superficiellement à voir avec cela. Il est plus généralement lié au partage de temps et à l'utilisation de plusieurs processeurs.
Le fait de n'avoir qu'un seul thread peut provoquer une famine pendant de longues opérations, qui peuvent être liées à la fois à IO et à des calculs complexes. Donc, même si la règle de base est un thread pr. core lors de l'utilisation d'E/S non bloquantes, il faut toujours considérer une taille de pool de threads suffisante pour que les requêtes simples ne soient pas affamées par des opérations plus complexes si elles existent. Plusieurs threads permettent également de diviser facilement des opérations complexes entre plusieurs processeurs. Un environnement à thread unique comme node.js ne peut utiliser des processeurs multicœurs qu'à travers davantage de processus et de messages pour coordonner l'action.
Personnellement, je n'ai pas encore vu d'argument convaincant pour introduire une technologie supplémentaire telle que node.js. Cependant, il peut y avoir de bonnes raisons, mais elles ont à mon avis peu à voir avec la maintenance d'un grand nombre de connexions via IO non bloquant, car cela peut également être fait avec ASP.NET.
BTW tamejs peut aider à rendre votre code nodejs plus lisible, similaire au nouveau CTP .Net Async à venir.
Il est facile de sous-estimer la différence culturelle entre les communautés Node.js et ASP.NET. Bien sûr, IHttpAsyncHandler existe et existe depuis .NET 1.0, donc cela pourrait même être bon, mais tout le code et la discussion autour de Node.js concernent E/S asynchrones, ce qui n'est décidément pas le cas en ce qui concerne .NET. Vous souhaitez utiliser LINQ To SQL? Vous pouvez en quelque sorte , en quelque sorte. Vous voulez enregistrer des trucs? Peut-être que "CSharp DotNet Logger" fonctionnera , peut-être.
Alors oui, IHttpAsyncHandler est là et si vous êtes vraiment prudent, vous pourrez peut-être écrire un service Web piloté par les événements sans trébucher sur des E/S bloquantes quelque part, mais je n'ai pas vraiment l'impression que beaucoup de gens utilisent (et ce n'est certainement pas le principal moyen d'écrire des applications ASP.NET). En revanche, Node.js concerne les E/S avec événements, tous les exemples de code, toutes les bibliothèques et c'est la seule façon dont les gens l'utilisent. Donc, si vous deviez parier sur le modèle d'E/S éventuel qui fonctionnait réellement tout au long, Node.js serait probablement celui à choisir.
Selon les améliorations technologiques actuelles et la lecture des liens ci-dessous, je peux dire que c'est une question d'expertise et de choisir un mélange parfait selon le scénario particulier qui compte. NodeJS devient mature et côté ASP.NET, nous avons ASP.NET MVC, WebAPI et SignalR etc. pour améliorer les choses.
http://www.salmanq.com/blog/net-and-node-js-performance-comparison/2013/03/ et
http://www.hanselman.com/blog/InstallingAndRunningNodejsApplicationsWithinIISOnWindowsAreYouMad.aspx
Merci.