asp.net - nodejs - node js getting started
¿Qué tan diferente sobre el evento de Node.js? ¿No podemos hacer eso en HttpAsyncHandler de ASP.Net? (4)
No tengo mucha experiencia en programación web, y aún no he codificado nada en Node.js, solo curiosidad por el enfoque orientado a eventos . Parece bueno.
El artículo explica algunas cosas malas que podrían suceder cuando utilizamos un enfoque basado en subprocesos para manejar las solicitudes, y debería optar por un enfoque basado en eventos en su lugar. En el hilo, el cajero / hilo está atascado con nosotros hasta que nuestro alimento / recurso esté listo. Si bien está orientado a eventos, el cajero nos envía a un lugar fuera de la cola de solicitudes para que no bloqueemos otras solicitudes mientras esperamos nuestra comida. Para escalar el bloqueo a base de subprocesos, necesita aumentar el número de subprocesos. Para mí, esto parece una mala excusa para no usar hilos / subprocesos correctamente.
¿No podría manejarse adecuadamente con IHttpAsyncHandler? ASP.Net recibe una solicitud, utiliza ThreadPool y ejecuta el controlador (BeginProcessRequest), y luego dentro de él cargamos el archivo / base de datos con una devolución de llamada. Ese hilo debe ser libre para manejar otras solicitudes. Una vez que se realiza la lectura del archivo, se vuelve a llamar al ThreadPool y se ejecuta la respuesta restante. No tan diferente para mí, ¿por qué no es tan escalable?
Una de las desventajas de los hilos que conozco es que el uso de hilos necesita más memoria. Pero solo con estos, puede disfrutar los beneficios de múltiples núcleos. Dudo que Node.js no esté usando ningún hilo / núcleo en absoluto.
Entonces, basándome únicamente en el argumento basado en eventos versus basado en hilos (no traiga el argumento "porque es Javascript y todos los navegadores ..."), ¿alguien me puede decir cuál es el beneficio real de usar Node.js en lugar de la tecnología existente?
Esa fue una pregunta larga. Gracias :)
De acuerdo con la edad actual de las mejoras tecnológicas y la lectura debajo de los enlaces, puedo decir que es cuestión de experiencia y elegir la mezcla perfecta según el escenario particular que importa. NodeJS está madurando y ASP.NET lado tenemos ASP.NET MVC, WebAPI y SignalR etc. para mejorar las cosas.
http://www.salmanq.com/blog/net-and-node-js-performance-comparison/2013/03/ y
http://www.hanselman.com/blog/InstallingAndRunningNodejsApplicationsWithinIISOnWindowsAreYouMad.aspx
Gracias.
En primer lugar, Node.js no tiene múltiples subprocesos. Esto es importante. Tienes que ser un programador muy talentoso para diseñar programas que funcionen perfectamente en un entorno enhebrado. Los hilos son difíciles.
Tienes que ser un dios para mantener un proyecto enhebrado donde no fue diseñado correctamente. Hay tantos problemas que pueden ser difíciles de evitar en proyectos muy grandes.
En segundo lugar, toda la plataforma se diseñó para ejecutarse de forma asíncrona. ¿Has visto algún proyecto ASP.NET donde cada interacción IO individual fuera asincrónica? en pocas palabras, ASP.NET no fue diseñado para ser controlado por eventos.
Luego, está la huella de memoria debido al hecho de que tenemos un hilo por conexión abierta y todo el problema de escala. Corrígeme si me equivoco, pero no sé cómo evitaría crear un nuevo hilo para cada conexión en ASP.NET.
Otro problema es que una solicitud de Node.js está inactiva cuando no se está utilizando o cuando está esperando IO. Por otro lado, un hilo C # duerme. Ahora, hay un límite en el número de estos hilos que pueden dormir. En Node.js, puede manejar fácilmente 10k clientes al mismo tiempo en paralelo en una máquina de desarrollo. Intenta manipular hilos de 10k en paralelo en una máquina de desarrollo.
JavaScript en sí mismo como un lenguaje facilita la codificación asincrónica. Si todavía estás en C # 2.0, entonces la sintaxis asincrónica es un verdadero dolor. Muchos desarrolladores simplemente se confundirán si está definiendo Action<> y Function<> todas partes y usando devoluciones de llamada. Un desarrollador ASP.NET promedio simplemente no puede mantener un proyecto ASP.NET escrito de una manera destacada.
En cuanto a hilos y núcleos. Node.js tiene un único subproceso y escala al crear procesos de múltiples nodos. Si tiene un núcleo 16, entonces ejecuta 16 instancias de su servidor node.js y tiene un equilibrador de carga Node.js único frente a él. (Tal vez un equilibrador de carga nginx si lo desea).
Todo esto fue escrito en la plataforma en un nivel muy bajo desde el principio. Esta no era una funcionalidad atornillada más adelante en la línea.
Otras ventajas
Node.js tiene mucho más que eso arriba. Lo anterior es solo la razón por la cual la forma en que maneja Node.js el bucle de eventos es mejor que hacerlo con capacidades asincrónicas en ASP.NET.
- Actuación. Es rápido. Realmente rápido.
- Una gran ventaja de Node.js es su API de bajo nivel. Tienes mucho control.
- Tiene todo el servidor HTTP integrado directamente en su código y luego lo subcontrata a IIS.
- Tienes toda la comparación de nginx vs Apache.
- Todo el desafío C10K se maneja bien por nodo pero no por IIS
- La comunicación AJAX y JSON se siente natural y fácil.
- La comunicación en tiempo real es una de las mejores cosas de Node.js. Fue hecho para eso.
- Se reproduce muy bien con bases de datos nosql basadas en documentos.
- Puede ejecutar un servidor TCP también. Puede hacer acceso a escritura de archivos, puede ejecutar cualquier comando de consola de Unix en el servidor.
- Consulta su base de datos en javascript utilizando, por ejemplo, CouchDB y map / reduce. Usted escribe su cliente en JavaScript. No hay interruptores de contexto mientras se desarrolla en su pila web.
- Rico conjunto de módulos de código abierto impulsados por la comunidad. Todo en node.js es de código abierto.
- Tamaño pequeño y casi sin dependencias. Puede construir la fuente node.js usted mismo.
Desventajas de Node.js
Es dificil. Es joven Como desarrollador experto de JavaScript, tengo dificultades para escribir un sitio web con Node.js solo por su naturaleza de bajo nivel y el nivel de control que tengo. Se siente como C. Mucha flexibilidad y poder ya sea para usarme o para colgarme.
La API no está congelada. Está cambiando rápidamente. Me imagino tener que volver a escribir un sitio web grande por completo en 5 años debido a la cantidad que Node.js se cambiará para entonces. Es factible, solo debe tener en cuenta que el mantenimiento en los sitios web de node.js no es barato.
Otras lecturas
http://blog.mixu.net/2011/02/01/understanding-the-node-js-event-loop/
Es fácil subestimar la diferencia cultural entre las comunidades Node.js y ASP.NET. Claro, IHttpAsyncHandler existe y ha existido desde .NET 1.0, por lo que incluso podría ser bueno, pero todo el código y la discusión en torno a Node.js se trata de asincronización de E / S, que definitivamente no es el caso cuando se trata de .NET. ¿Quieres usar LINQ to SQL? Tu puedes , tipo de. ¿Quieres registrar cosas? Quizás "CSharp DotNet Logger" funcione , tal vez.
Así que sí, IHttpAsyncHandler está ahí y si eres realmente cuidadoso podrías escribir un servicio web impulsado por eventos sin tropezar con alguna E / S de bloqueo en alguna parte, pero realmente no tengo la impresión de que mucha gente está usando (y ciertamente no es la forma más destacada de escribir aplicaciones ASP.NET). Por el contrario, Node.js se trata de E / S con evented, todos los ejemplos de código, todas las bibliotecas y es la única forma en que las personas lo utilizan. Entonces, si ibas a apostar por el modelo de E / S que más te interesaba, Node.js probablemente sería el que elegiría.
Hay muchos conceptos erróneos con respecto a node.js vs. ASP.Net y programación asincrónica. Puede hacer IO sin bloqueo en ASP.NET . La mayoría de las personas no saben que .Net Framework usa los puertos de completación de Windows debajo cuando realiza llamadas al servicio web u otras operaciones de E / S vinculadas utilizando el patrón de inicio / finalización en .Net 2.0 y superior. Los puertos de terminación de E / S son la forma en que el sistema operativo de Windows admite E / S no bloqueantes para que la cadena de la aplicación se libere por qué se completa la operación de E / S. Curiosamente, node.js utiliza una implementación de E / S no bloqueante menos óptima en Windows a través de Cygwin. Una nueva versión de Windows está en la hoja de ruta, que con la guía de Microsoft utilizará IO completions ports. En ese momento, no hay diferencia.
También es posible realizar llamadas de bases de datos no bloqueantes en ADO.NET, pero tenga en cuenta las herramientas ORM como NHibernate y Entity Framework. Todavía son muy sincrónicos.
Synchronous IO (blocking) hace que el flujo de control sea mucho más claro y, por este motivo, se ha hecho popular. La razón por la que los entornos informáticos son multiproceso solo tiene que ver superficialmente con esto. En general, está relacionado con el uso compartido del tiempo y la utilización de múltiples CPU.
Tener solo un hilo puede causar inanición durante operaciones largas, lo que puede relacionarse tanto con IO como con cálculos complejos. Entonces, a pesar de que la regla de oro es un hilo pr. núcleo cuando se utiliza IO no bloqueante, aún se debe considerar un tamaño de grupo de subprocesos suficiente para que las solicitudes simples no se vean privadas de operaciones más complejas, si es que existen. Múltiples hilos también permite que las operaciones complejas se dividan fácilmente entre múltiples CPU. Un entorno de subproceso único como node.js solo puede utilizar procesadores multinúcleo a través de más procesos y pasar mensajes para coordinar la acción.
Personalmente, aún no he visto ningún argumento convincente para introducir una tecnología adicional, como un node.js. Sin embargo, puede haber buenas razones, pero en mi opinión tienen poco que ver con el mantenimiento de una gran cantidad de conexiones a través de IO no bloqueante, ya que esto también se puede hacer con ASP.NET.
Por cierto, los tamejs pueden ayudar a que el código de su nodo sea más legible, similar al nuevo .Net Async CTP.