¿Es Node.js lo que necesito?

[jerkan]

Preocupado por el rendimiento de una aplicación que estoy desarrollando, descubrí Node.js y me pareció muy interesante aunque no tengo claro si sería lo que yo necesito.

Mi aplicación está desarrollada en PHP+jQuery. El servidor lee y agrupa datos de internet y los sirve a los clientes. Ahora mismo, cada cliente (jQuery) realiza un polling (consulta) cada x minutos para saber si hay actualizaciones (aquí está mi preocupación sobre el rendimiento).

¿Node.js mejoraría esta estructura?

Gracias

[dggluz]

En realidad, debes fijarte en los logs para ver dónde está el cuello de botella. Si el cuello de botella está en el servidor web, entonces NodeJS puede ser tu solución. De todos modos, también podrías probar con otro servidor que maneje PHP, para no tener que reprogramar todo (puedes probar Nginx, si es que estás utilizando Apache, tiene menos overhead). Si el cuello de botella está en tu BD, entonces deberás optimizar las consultas y el servidor de BD. De nuevo, los logs son la mejor herramienta para investigar. Incluso puedes evaluar cambiar de SGBD, o de tipos de tablas (por ejemplo, suponiendo que usara MySQL, podrías reemplazar las tablas InnoDB, por MyISAM, que son más veloces para las lecturas, pero debes tener en cuenta que éstas no soportan transacciones). Obviamente, saber qué indexar y cuándo es fundamental, lo mismo que saber normalizar y denormalizar la BD.
Otra opción es tirarle más procesamiento al cliente para aliviar el del servidor... por ejemplo, en lugar de armar gráficos en PHP, ármalos en el cliente con JavaScript.
Por eso lo primero es averiguar dónde está el cuello de botella. ¡Suerte!

[alejandromg]

Definitivamente es tu mejor opción.

Realmente no se tanto PHP y no lo conozco tan a fondo para sacarlo a comparación, pero si conozco bastante a node.js, y déjame decirte que un punto muy importante en la filosofia de node.js es eso misma: "Crear aplicaciones en Tiempo Real", el long-polling ya no es muy necesario con node.js, además del uso de websockets lo simplifica, y mucho más con la estructura que tu mencionas.

En cuanto a rendimiento te sorprenderás con los benchmarks, Felix Geisendörfer (core-developer de node.js) menciona en un twitt (https://twitter.com/#!/felixge/status/69372032646778880) que node.js puede ejecutar hasta 1.6 milliones de conexiones concurrentes en un servidor HTTP mediante un único socket antes de que se el servidor se quede sin memoria. Asi que por concurrencia no tendrías problemas, teóricamente. Otro benchmark, realizado por el Arnout Kazemier (Ganador del nodeknockout) pone a prueba el rendimiento de node.js (http://blog.3rd-eden.com/post/580907...me-performance) los cuales ayudarían a establecer un fundamento mejor con respecto a tu preocupación.

Ahora en el escenario node.js, no ocupas estar realizando llamadas a tu servidor cada x minutos, usa socket.io el cual simplemente se encarga de "distribuir" a través de websockets a cada uno de los clientes conectados, aparte provee una forma muy segura, eficaz y rápida para distribuir correctamente los mismos.

Sinceramente, yo escogeria node.js, ya que es el escenario perfecto para el mismo.

Ahora bien, que herramientas (en caso que te decidieras) ocuparías:

- socket.io (http://socket.io/)
- ¿Muy complicado socket.io?, échale un vistazo a nowjs (basado en socket.io) (http://nowjs.com).
- Express como framework (expressjs.com)
- Para sacarle mayor rendimiento a tu aplicación y en caso que quieras persistencia de datos: couchdb o redis (redis.io, revisa la sección de Pub/Sub) deberían de ser parte de tu elección.

Node.js sin duda esta creciendo últimamente, tanto en capacidad como en madurez. Sin duda tenlo en cuenta y en el top de tu lista en cuanto a este tipo de aplicaciones.

Edit. Si ya la tienes desarrollada, sin duda tu mejor opción es realizar pruebas de estrés y ver como reacciona, como dijo @dggluz los logs son siempre tus aliados.

[jerkan]

Gracias a dggluz y alejandromg por vuestras respuestas.

Le he estado dando vueltas en cómo implementar sockets y he aquí lo que se me ocurrió:

·En el servidor, debería crear un cronjob que llamara a un script PHP que mirara si hay actualizaciones en internet.
·Si las hay, PHP debería de ponerse en contacto con el socket-server para que este notificara a los clientes socket.

Para el segundo punto, he encontrado una librería llamada DNode que podría ser de ayuda. ¿La conocéis?

Sin embargo, también encontré que el propio PHP ofrece soporte a sockets. Para mi caso, ¿no sería mejor utilizar sockets PHP en el servidor?

Por otro lado, parece que conocéis bien el tema de las pruebas de estrés. ¿Me podéis recomendar alguna aplicación para realizarlas?

Gracias de nuevo.

[dggluz]

Yo en realidad nunca realicé test de estrés. Lo que sí te puedo decir es que los logs (que dependen de qué servidores uses) dan mucha información. En realidad... ¿por qué te preocupa el rendimiento de la aplicación que estás desarrollando? (digo, ¿qué te da el indicio de que podría andar mal?).

[jerkan]

Iniciado por dggluz

Yo en realidad nunca realicé test de estrés. Lo que sí te puedo decir es que los logs (que dependen de qué servidores uses) dan mucha información. En realidad... ¿por qué te preocupa el rendimiento de la aplicación que estás desarrollando? (digo, ¿qué te da el indicio de que podría andar mal?).

Pues, por un lado, veo un montón de llamadas por cliente para ver si hay actualizaciones que lo único que hacen es saturar el servidor.

Por otro lado, si necesito menos recursos (utilizando sockets) menos me costará el servidor donde aloje la aplicación.

[dggluz]

Mmmm... entonces sí te convendría usar NodeJs con COMET. No sé mucho de eso, porque nunca los utilicé, pero tengo entendido que tienen el fuerte en aplicaciones como la tuya. Por otro lado, dependiendo de tus necesidades, quizás debas investigar las bases de datos NoSQL, como MongoDB, CouchDB, Redis, Cassandra, BigTable, etc.
Eso sí, es muuuuucho lo que tienes para investigar. ¡Suerte!

[alejandromg]

Iniciado por jerkan

Pues, por un lado, veo un montón de llamadas por cliente para ver si hay actualizaciones que lo único que hacen es saturar el servidor.

Cuando mencionas esto, definitivamente algo estas haciendo mal dentro de tu código, que genera esta "saturación", el posible caso sea que dejas abiertas cada una de las conexiones provocando que tu servidor se sobrecargue.

Ahora bien DNode es un monstruo, su creador un genio (substack), y sin duda la manera de comunicar PHP con node.js es una gran idea ya que te evita rescribir código funcional, y aprovechar las facilidades que Node te ofrece. Yo ya he utilizado DNode y funciona bastante bien (sin PHP) pero la documentación para este es bastante buena. Sin duda es una opción.

En cuanto a pruebas de estrés me refiero a el Apache HTTP Benchmark tool (http://httpd.apache.org/docs/2.0/programs/ab.html) simplemente así:

ab -c 1000 -n 1000 127.0.0.1:PUERTO/P/A/T/H

Para realizar 1000 request (n) con una concurrencia de 1000 (c) y ver que es lo que realmente sucede, claro esto es lo que te va a generar los logs que menciona dggluz y ver donde es que realmente tienes problemas.

Otras es utilizar selenium (http://seleniumhq.org/) o este servicio (https://browsermob.com/website-load-testing) pero como supongo lo tienes en tu localhost el apache benchmark seria el más conveniente.

[alejandromg]

Iniciado por dggluz

Mmmm... entonces sí te convendría usar NodeJs con COMET.

Websockets >>> COMET. Comet es un hack para hacer funcionar las aplicaciones realtime de una manera más eficaz. De igual forma comet require mantener una gran cantidad de conexiones abiertas además mantiene un thread por conexión (y eso no es escalable).

Mira, acabo de acordarme de pusher (http://pusher.com/) que es una startup que te ofrece un servicio a través de websockets definitivamente debes de darle un vistazo y los planes son bastante aceptables.

[Dnielf]

Node.js al ser no bloqueante (es más rápido que PHP) será útil si tu aplicación recibe alta concurrencia, por ejemplo 1000 usuarios que al mismo tiempo hacen la petición. Pero eso no es todo y de seguro es pesado migrar toda tu aplicación a node.js, así que ...

Investigando un poco, el rendimiento de tu aplicación será regido por qué tan rápido haces esa "agrupación" de datos de internet (uses php o no), para lo cual es mejor usar workers. Puede usar node.js como complemento de php u otras implementaciones, de seguro quieres que haya una respuesta rápida al usuario, con un proceso de fondo puedes mandar parte de la respuesta cada cierto tiempo al mismo. PHP atiende las peticiones, manda el trabajo a node.js e inmediatamente pasa a atender otra petición, node.js a su vez envía información a través de websockets por ejemplo.


http://devcenter.heroku.com/articles/queueing
Al parecer es similar a tu caso y con node.js no le basta
http://stackoverflow.com/questions/8...e-with-node-js

[eucm2]

DE HEHCO YO TAMBIEN DESARROLLE UNA APLICACION QUE CONSULTABA CADA 10 SEGUNDOS EL ESTADO DE MIS USUARIOS (CON AJAX) Y EL PROBLEMAS ES QUE TENIA QUE ESTAR HACIENDO PETICIONES A MI SERVIDOR EN ARGENTINA (YO ESTOY EN MEXICO) ASI QUE TARDABA RELATIVAMENTE ALGO EN LLEGAR LA PETICION Y REGRESARLA. AHORA NODE.JS TRABAJA SOBRE EVENTOS ESTO SIGNIFICA QUE LAS ACCIONES QUE HAGA UN USUARIO LA SPUEDEN VER LOS DEMAS EN EL MOMENTO QUE ESTE LOS HACE.

OTRO CLARO EJEMPLO SON LOS CHAT. CON JAVASCRIPT Y/O JQUERY SE TIENE QUE ESTAR REFRESCANDO PARA VER SI EL OTRO USUARIO ENVIO ALGUN MENSAJE MIENTRAS QUE NODEJS DETECTA EL MOMENTO EN EL QUE EL USUARIO ENVIA EL MENSAJE, ESTE ES ENVIADO AL O A LOS SUARIOS QUE SE DEFINAN, LOS CUALES TAMBIEN DETECTAN EL MOMETO EN QUE SE ENVIA UN MENSAJE.

AHORA LA UNICA DESVENTAJA QUE TIENE NODEJS VS PHP ES QUE NODEJS NO ESTA DADO DE ALTA EN LA MAYORIA (GRAN MAYORIA) AQUI ESTA UNA LISTA DE SERVIDORES GRATUITOS DE NODE JS http://www.nodehispano.com/. EN MI CASO PARTICULAR NINGUNO DE ESTOS ME SIRVE ASI QUE TUBE QUE INSTALAR NODEJS EN MI VPS (SERVIDOR PRIVADO VIRTUAL) OBVIO QUE YO PAGUE (DATTATEC.COM PLAN VPS ESTA EN 3000 pesos mx).