surveymonkey - Escalar una aplicación de chat: encuestas cortas frente a encuestas largas(AJAX, PHP)

software para encuestas (3)

Dirijo un sitio web donde los usuarios pueden chatear entre sí a través del navegador (piense en el chat de Facebook). ¿Cuál es la mejor manera de manejar la interacción en vivo? (En este momento tengo una encuesta cada 30 segundos para actualizar a los usuarios en línea y los nuevos mensajes entrantes, y otra encuesta para las páginas de chat cada segundo para recibir mensajes nuevos).

Cosas que he considerado:

Sockets web HTML5: no lo usé porque no funciona en todos los navegadores (solo Chrome).
Flash Sockets: no lo usé porque finalmente quería dar soporte a la web móvil.

En este momento, estoy utilizando encuestas cortas porque no sé cuán escalables serían las encuestas largas AJAX. Estoy ejecutando un servidor VPS desde el servidor en este momento (ejecutando Apache). ¿Debo usar encuestas largas o encuestas cortas? No necesito tiempos de respuesta absolutamente inmediatos (solo "lo suficientemente bueno" para una aplicación de chat). ¿Las encuestas cortas a menudo con unos cientos de miles de usuarios van a matar a mi servidor? Cómo escalo esto, por favor ayuda!

Algunas notas:

Sondear cada segundo es excesivo. La aplicación todavía se sentirá muy receptiva con unos segundos de demora entre los controles.
Para guardar el tráfico de su db y las respuestas de velocidad, considere usar una memoria caché en la memoria para almacenar los mensajes no entregados. Todavía podría persistir mensajes a la base de datos, la memoria caché en la memoria simplemente se utilizaría para las consultas de mensajes nuevos para evitar consultas a la base de datos cada x segundos por cada usuario.
Agote el tiempo de espera del chat del usuario después de x segundos de inactividad para detener el sondeo a su servidor. Esto asegura que alguien que deje una ventana abierta no continuará generando tráfico. Ofrezca un simple "¿Todavía está allí? Continúe chateando". enlace para las sesiones que exceden el tiempo y advierten al usuario antes del tiempo de espera para que puedan extender el tiempo de espera.
Sugiero comenzar con sondeos en lugar de cometas / sondeos largos. El sondeo es simple de construir y de soporte, y probablemente se escalará muy bien en el corto plazo. Si obtiene mucho tráfico, puede lanzar hardware y un equilibrador de carga al problema para escalar. Toda la web se basa en sondeos: las encuestas sin duda escalan. Hay un punto en el que la complejidad de alternativas como cometa / largo sondeo / etc. tiene sentido, pero se necesita mucho tráfico antes de justificar el tiempo / complejidad de desarrollo adicional.

Esto es algo que todos hicieron una vez antes de la introducción de cometd y nodejs.

El problema, como veo, es que las solicitudes de PHP en Apache son muy costosas. Si su aplicación de chat comprueba los mensajes cada segundo, se encontrará en una situación en la que Apache no tiene suficientes recursos para responder a las solicitudes. La otra área que creo que necesita mejorar es mejorar el contexto de su aplicación de chat.

¿Por qué se actualiza cada segundo si no se recuperan los mensajes nuevos? ¿Qué pasa si no hay mensajes?

Algunas técnicas que puedes usar;

Proporcione un punto final liviano a sus clientes que tenga algún contexto sobre la sesión de chat, un mensaje nuevo pendiente, cuántos mensajes, etc. El cliente puede responder actualizando de inmediato o no si no hay mensajes nuevos. Este punto final puede proporcionar un objeto json simple a través de la solicitud http. Se le garantiza que este mensaje de estado tendrá un tamaño fijo y, si la respuesta del estado no cambia, puede degradarlo. Ver el siguiente mensaje.
Un decaimiento simple en su sondeo de javascript, si el cliente recibe la misma respuesta del servidor varias veces seguidas, puede incrementar el sondeo en un tiempo determinado, en este momento dijo que era cada segundo. Si hicieras esto aumentarías a cada 2,4,6,8,10 segundos. Tan pronto como cambia la respuesta del servidor, restablece la descomposición.

Algunas optimizaciones a considerar;

Use un caché PHP Opcode como APC.
Establezca un tiempo de espera bajo en todas las solicitudes, no desea que ninguna solicitud cuelgue su servidor.
Optimice su código PHP, agilice y acelere.
Ejecute algunas pruebas de carga para ver cuáles son sus límites.
Rendimiento de referencia a menudo para asegurarse de que sus aplicaciones sean cada vez más rápidas.
Verifique los registros de apache para ver los signos de la salud general de la aplicación y los tiempos de respuesta.

Cuando sea necesario escalar, agregue un nuevo servidor y use un equilibrador de carga para distribuir las solicitudes. He usado Barniz y HAProxy con gran éxito, configurarlos tampoco es complicado.

Si yo fuera usted, elegiría una biblioteca que use conectores web html5 pero que se vuelva a enchufar en las tomas flash si html5 no está disponible, el navegador que caiga en la grieta debería ser diminuto.

También debe abandonar php o complementarlo con un servidor de socket con hebras escrito en python o ruby con em-websocket.