Node.js y ruby

2,395 views

Published on

Introducción a node.js para la rubyconf de uruguay

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,395
On SlideShare
0
From Embeds
0
Number of Embeds
18
Actions
Shares
0
Downloads
17
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide



  • Desde los 70 se usó el modelo de un proceso por conexión en los servidores web.
    Cada proceso instanciado requiere una cantidad de recursos importante.
    El scheduler del sistema operativo se vuelve más lento con más procesos.
    Este método no escala.


  • Los threads coexisten en un mismo proceso compartiendo recursos como memoria
    Los green threads, threads manejados por la MV, son por lo general más rápidos que los threads pero demoran más en cambiar de contexto.
  • Los event loops constan de un sólo proceso que está constantemente seleccionando eventos y procesándolos.
    Se puede evitar el overhead de los multiples stack de ejecución
  • 2 ejemplos claros de servidores que implementan cada uno uno de estos modelos son Apache y nginx.
    Apache en un principio tenía un proceso por conexión. Luego con un módulo usaba un thread por conexión.
    Nginx usa un loop de eventos simple.

  • En la gráfica vemos qué nginx soporta más req/sec y que la distancia aumentan a medida que aumentan los usuarios
  • Como apache levanta un thread por cada evento, la cantidad de memoria aumenta linealmente con la cantidad de requests.
    Nginx por otro lado requiere una cantidad constante de memoria.
  • Lo fundamental para que el event loop funcione correctamente es que cada evento se procese de la manera más rápida posible.
    El mayor riesgo en ese sentido son las operaciones de E/S
    Mientras que el acceso a memoria volátil demora a lo sumo cientos de ciclos de CPU, acceder a disco o a red consume millones de ciclos de CPU


  • Este tipo de código bloquea todo el event-loop, estamos esperando a que se termine de ejecutar un operación costosa y mientras tanto no estamos procesando otras conexiones.
  • El programa continúa con la ejecución normal, dejando un puntero a una función que se va a ejecutar cuando se termine de procesar la operación de E/S.

    Node se basa en la primicia en que así se debe manejar la E/S

    Todo acceso a base de datos, a disco o a red tiene que realizarse mediante un callback.

    Node nos brinda librerías no bloqueantes para algunos protocólos básicos de la web como HTTP, DNS, TCP

  • Hay multiples plataformas en otros lenguajes (eventMachine para ruby, twisted para python, etc)

    Los desarrolladores javascript están acostumbrados a desarrollar orientado a eventos

    Un lenguaje como javascript es ideal para implementar callbacks ya que las funciones son ciudadanos de primera clase en Javascript.

    V8 es rápido y hay muchos compitiendo por hacer javascript más rápido

  • - No tenemos todas las gemas del mundo ruby
    - El stop-the-world garbage collection de V8 puede traer problemas cuando se está consumiendo mucha memoria
    - Casi todas son solucionables
  • En realidad podemos utilizar node para cualquier tipo de servidor web

    Es particularmente util para aplicaciones en tiempo real usando comets
  • Vemos que hacer polling es menos eficiente, se hacen pedidos sin respuesta, demoramos más en tener los datos del servidor, etc

    Pero se necestia mantener muchas más conexiones abiertas y eso con el modelo de un thread por conexión no es escalable








  • ×