Escalar una aplicación de chat - encuestas cortas versus encuestas largas (AJAX, PHP)

Question

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 un sondeo de ir cada 30 segundos para actualizar usuarios en línea y los nuevos mensajes entrantes, y otra encuesta pasando las páginas de chat cada segundo para conseguir nuevos mensajes.)

Cosas que me he considerado:

• Web socket HTML5: no usé esto porque no funciona en todos los navegadores (solo Chrome).
• Sockets de memoria flash: no lo usé porque finalmente quería dar soporte a la web móvil.

En este momento, estoy utilizando un sondeo corto porque no sé cuán escalable sería el largo sondeo 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!

Answer 1

Unas pocas notas:

• sondeo cada segundo es una exageración. La aplicación todavía se sentirá muy receptiva con unos segundos de demora entre los controles.
• Para guardar el tráfico de su base de datos 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/sockets. 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.

Answer 2

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

El problema, como yo lo veo, es que las solicitudes de PHP en Apache son muy caras. 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 puede usar;

• Proporcionar un punto final de peso ligero a sus clientes que tiene un poco de contexto acerca de la sesión de chat, es un mensaje nuevo en espera, la cantidad de mensajes, etc. El cliente puede responder a esta mediante la actualización de inmediato o no si hay 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 simple decaimiento 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 tener en cuenta;

• Utilice una memoria 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, hágalo ligero y rápido.

• Ejecute algunas pruebas de carga para ver cuáles son sus límites.

• Compare el rendimiento a menudo para asegurarse de que sus aplicaciones sean cada vez más rápidas.

• Revise los registros de Apache para detectar 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.

Answer 3

Si yo fuera usted elegiría una biblioteca que utiliza conectores web html5 pero se cae de nuevo en las tomas flash si html5 no está disponible, el navegador que caiga por 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.