Constantly Querying Server a través de Javascript - ¿Buena idea?

Question

Tengo un sitio web pequeño que tiene aproximadamente de 5 a 10 administradores. Lo configuré para monitorear lo que hace cada administrador (agregar elementos, eliminar elementos, etc.). Tenía una lista dentro de nuestro panel de administración que muestra las 10 actividades anteriores realizadas por la administración colectiva. Hoy, decidí hacer esta actualización automática cada 30 segundos.

Mi pregunta es simple: ¿hay algún problema para hacer esto? Llamo un poco de texto con cada solicitud, y es probable que la solicitud solo se ejecute en 3 o 4 computadoras a la vez (lo que refleja el número de administradores simultáneos que iniciaron sesión).

$(document).ready(function(){ 
    setInterval("activity()", 30000); 
    }); 

    function activity() { 
    $("#recent_activity").load("../home/login #recent_activity .data"); 
    } 

Produce lo siguiente (o similar, solo con 10 filas) con cada solicitud.

<table> 
    <tbody> 
    <tr> 
     <td><p>jsampson</p></td> 
     <td><p>logged out</p></td> 
     <td><p>28 minutes 27 seconds ago</p></td> 
    </tr> 
    <tr> 
     <td><p>jdoe</p></td> 
     <td><p>logged in</p></td> 
     <td><p>29 minutes 45 seconds ago</p></td> 
    </tr> 
    </tbody> 
</table> 

Answer 1

3-4 usuarios cada 30 segundos no es mucho. Incluso 300 usuarios a esa velocidad no serían en absoluto.

Es posible que desee comprobar en estas preguntas:

• Should I use Ajax Push or Pull
• Simple Long Polling Example Code

Usted puede caché esto también, y sería aconsejable especialmente si la consulta a generar la página es computacionalmente pesado, pero por supuesto, tenga en cuenta qué tipo de retraso desea en el contenido más reciente sea ing mostrado.

Answer 2

No creo que suponga un problema.

Answer 3

No, no debería haber ningún problema en absoluto. Hago lo mismo con intervalos de 1 minuto para un sistema de notificación que escribí en el portal de la intranet de mi compañía. Cualquier servidor web debería ser capaz de manejar esto, honestamente.

Realmente no es peor (de hecho, significativamente mejor) que ellos, por ejemplo, refrescando su navegador cada 30 segundos ... Teniendo en cuenta la transferencia de datos significativamente más pequeña, probablemente sería algo en la escala de 10-20 veces mejor que refrescarlo ... o aproximadamente el mismo ancho de banda de refrescante una vez cada 5-10 minutos. :-)

Answer 4

Debe almacenar en caché esto y solo actualizar la caché cada 30 segundos.

Answer 5

No hay problema en absoluto en mi opinión. Los sitios que se ejecutan en una escala mucho mayor (Betfair, por ejemplo) usan cientos de llamadas xhr por minuto por cliente conectado. Obviamente tienen infraestructuras de hardware mucho más grandes, pero el navegador funciona bien.

Tengo sitios que utilizan un intervalo más pequeño y se escalan a unos pocos cientos de usuarios simultáneos que se ejecutan desde un servidor web simple.

Answer 6

Yo diría que dependería principalmente de qué tan costosa es esa consulta.

Aunque ahora hay pocos usuarios, ¿siempre será así?

Answer 7

Como señaló altCognito, es probable que el tráfico web no sea un problema.

Lo único que comprobaría es si la carga de la base de datos requerida para esto será un problema. Es decir. si esto es alimentado por una consulta que toma tiempo para ejecutarse, causará problemas. Sin embargo, si ese es el caso, recomendaría agregar algo de almacenamiento en caché a los datos, o mantener los datos para esto en la memoria en lugar de la base de datos (solo cargar desde la base de datos al inicio y agregar elementos a esta lista en la memoria del servidor como Ellos pasan).

Answer 8

Péselo contra la alternativa. Si cada usuario estuviera actualizando la página cada 30 segundos, cargando toda la página, la cantidad de procesamiento del lado del servidor y el tráfico generado sería mucho mayor que simplemente refrescar las "partes interesantes".

Esto es para lo que AJAX se hizo.

Answer 9

¿Has visto el Google Wave vista previa ...? Para un número tan pequeño, esto no es un problema, especialmente porque los administradores lo sabrán. (No es como si estuviera cargando un poco la CPU de un visitante o la conexión a Internet móvil).

Answer 10

Que muchos usuarios no van a derribar su servidor.

Si está realmente preocupado por el rendimiento, te daré consejos 2:

• Uso de JSON para enviar datos al cliente, será más ligero que el formato HTML.

• Utilice la fecha fija para los datos del historial y calcule el tiempo relativo en el cliente, le permitirá almacenar en caché los datos del historial.

  {"user":"jsampson","action":"logged out","date":"20090622T170822"}

Answer 11

Sí, esto no debería ser un problema en lo más mínimo.

Dicho esto, si le preocupa la cantidad de datos que se envían, siempre puede hacer que la llamada envíe una señalización simple SI hay datos nuevos y luego buscar los datos si ese es el caso.

Pero sí, con ese número de usuarios no debería tener ningún problema. Un tablero de mensajes personalizado basado en RoR que frecuento utiliza una técnica similar para ver si los hilos se han actualizado mientras lo está leyendo y tiene más de 100 usuarios que lo golpean al mismo tiempo sin ningún problema.

Answer 12

Hay varias formas diferentes de emular el servidor push a través de HTTP. Dichas técnicas obtuvieron recientemente un nombre elegante: Comet.

Si la configuración de su servidor permite la ejecución indefinida de scripts, puede usar un iframe para implementar el panel y usar transferencias fragmentadas (por ejemplo, a través del flush() de PHP) para crear una conexión HTTP persistente. Tal solución debería tener la menor sobrecarga si el intervalo de tiempo entre mensajes consecutivos es corto. Para intervalos largos, es preferible el sondeo del lado del cliente, ya que no se debe mantener ninguna conexión TCP.

Answer 13

Creo que lo que hizo es genial.

Si estuviera haciendo este proyecto, comenzaría con lo que tiene y agregaré un evento setTimeout() para incrementar la visualización de minutos/segundos cada segundo.

Los usuarios percibirían que la pantalla es en tiempo real, y probablemente nunca llegarían a la actualización de la página.

El peligro de la actualización solo cada 30 segundos es que algunas personas actualizarán de forma refleja la última palabra cada vez que dirijan su atención hacia ella.

Considere marcar especialmente cualquier cosa con un tiempo de menos de cinco minutos. Y la codificación de color inició sesión en comparación con la sesión cerrada. Será más fácil para las personas "escanear" porque podrán elegir cambios sin leer todo el texto.