Socket.IO: ¿son las conexiones abiertas una preocupación?

Question

Actualmente estoy trabajando con DerbyJS porque fomenta el código limpio, cliente/servidor DRY. El beneficio lateral (razón principal por la cual la mayoría de las personas usa el marco) es que usa Socket.IO para crear aplicaciones en tiempo real. En este caso, yo no necesita en tiempo real, pero es una buena adición.

Mi pregunta es: ¿estoy sacrificando la escalabilidad/rendimiento usando Socket.IO, y todas esas conexiones abiertas que mantiene? ¿El uso de Backbone + ExpressJS liberaría recursos ya que no hay conexiones abiertas?

Answer 1

Mantener un montón de conexiones abiertas obviamente tiene algún costo en términos de sobrecarga del servidor, pero no me preocuparía por preocupaciones como esta a menos que tenga un problema obvio de escalado. Una vez que tenga un problema de escalamiento obvio, debe tener suficientes ingresos para comprar más recursos de servidor. Los servidores son muy baratos y tu tiempo es muy caro. No te preocupes por optimizar las cosas pequeñas.

Answer 2

¿Estoy sacrificando la escalabilidad/rendimiento usando Socket.IO, y todas las conexiones abiertas que mantiene?

Si desea actualizar su página (página dinámica) inmediatamente cuando haya nueva información disponible. Luego, mantener la conexión abierta usando no bloqueo io es la forma más eficiente de hacerlo. Afortunadamente node.js usa io no bloqueante. Esa es una de las razones por las que node.js es tan popular (además de que puede codificar en JavaScript, que es el lenguaje de programación más popular). Si realmente no lo necesita (también en el futuro) porque su sitio web es bastante estático (no en tiempo real como usted dijo) entonces cerrar la conexión le ahorrará recursos.

¿Utilizaría Backbone + ExpressJS recursos gratuitos ya que no hay conexiones abiertas?

Me gustaría ver el costo (tiempo de desarrollo) para desarrollar su sitio web utilizando la combinación backbone/express versus derbyjs.

Luego, de nuevo como Nate mencionado Socket.io puede manejar muchas (1000+) conexiones concurrentes fácilmente. Si es más fácil desarrollar usando derbyJS entonces lo usaría. Cuando cruzas ese camino, siempre puedes decidir agregar más servidores o rediseñar (puedes contratar programadores adicionales) tu sitio web para usar la combinación de expreso/red troncal. Primero intente llegar a un punto en el que los usuarios encuentren que su sitio web es valioso con el menor esfuerzo (tiempo de desarrollo).

P.S: Creo que deberías tratar de mantener tu sistema lo más modular posible para que reemplazar Derby.js por otra cosa se pueda hacer con la menor cantidad de tiempo posible.