¿Usar AJAX mejoraría ampliamente el rendimiento del servidor?


10

Claramente, AJAX mejora la interfaz de usuario, pero ¿esto también disminuye la carga del servidor? Pensarías que sí, porque no será necesario publicar toda la página cada vez, pero tal vez hay otras variables que no estoy considerando.

Respuestas:


14

Depende de lo que esté haciendo y de cómo lo esté haciendo.

  • Si está reemplazando cargas de página completa con solicitudes AJAX (es decir, solo haciendo llamadas AJAX cuando un usuario hace clic en lo que habría sido una carga de página completa), entonces AJAX disminuirá la carga del servidor porque (presumiblemente) está procesando menos y devolviendo menos datos.

  • Por otro lado, si está agregando el tipo de actualización automática AJAX que sondea el servidor cada pocos segundos, eso podría aumentar la carga dependiendo del usuario (es posible que no aumente la carga del servidor si el usuario sigue presionando F5 para actualizar manualmente de todos modos, pero la mayoría de la gente generalmente no hace eso por horas)

  • Otra optimización de AJAX es cargar solo más datos a medida que se desplaza. En ese caso, si el usuario no se desplaza completamente hacia abajo, es un procesamiento desperdiciado.

Por supuesto, la implementación en realidad puede sesgar los resultados de cualquier manera, estos son resultados típicos suponiendo implementaciones razonablemente buenas.


La verdadera pregunta aquí es qué cambia cuando te mueves a una forma AJAX de hacer las cosas. ¿Eres capaz de eliminar el trabajo que se estaba desperdiciando antes al pasar a AJAX, o simplemente dividirlo en pedazos más pequeños? (y agregando gastos generales en el proceso)
SplinterReality

3

Por supuesto, sirve para disminuir la carga del servidor. Mire esta presentación @ jsconf'09 : cómo Facebook usó ajax para hacer eso.

Ajax es asíncrono. comunicación del servidor, y puede usarla de muchas maneras. La gente lo usa para cargar JSON simple a la Web en tiempo real, y todo lo demás.

Recuerde: el verdadero desafío es el equilibrio entre el cliente y el servidor. Esfuércese por hacer que cada parte haga su trabajo de manera que el sistema esté optimizado y obtenga beneficios obvios de la capacidad de respuesta percibida y la velocidad real.


3

Hay otros factores que no está considerando: en la mayoría de los casos, AJAX aumentará la carga del servidor. En un escenario típico que no es ajax, un usuario carga una página grande cada pocos segundos o pocos minutos. Sí, esa única página es un poco más de trabajo para el servidor, pero tiene mucho tiempo entre solicitudes para recuperar y servir otras solicitudes. En un escenario AJAXified, esa carga de una sola página ahora es decenas de pequeñas visitas, constantemente martillando el servidor y esperando respuestas.

Es un poco como la muerte de 1000 cortes: ninguna de las solicitudes es tan grande en sí misma, pero el peso total es mortal. Especialmente cuando comienzas a considerar que estas pequeñas solicitudes son tan caras de servir como una solicitud de página completa. En ambos casos, probablemente esté ejecutando una tubería de aplicación web completa, golpeando una base de datos y esperando una respuesta mientras se encuentra en una preciosa conexión HTTP.

Aquí hay un ejemplo de cómo ajax puede ponerse feo en el servidor muy rápido. Tomemos un típico "tablero ejecutivo" que presenta 4 ranuras para widgets. Digamos que al CEO le gusta un informe de ventas completo en el lado derecho, una lista de los 10 principales ganadores en el medio y un informe de precios de acciones de la compañía a la derecha. Y digamos que vamos a hacer esto a través de simples solicitudes remotas ajax. Sin tener en cuenta las hojas de estilo, las imágenes y otros activos, su página ahora requiere 4 viajes de ida y vuelta HTTP (página principal, cada uno de los informes del tablero) contra el servidor. Cada uno de estos requiere una pila web completa para ejecutarse: vas a acceder a bases de datos y renderizar HTML usando tu marco web, ¿verdad? Ahora multiplique el CEO único por 2000 usuarios remotos, algunos de los cuales tienen conexiones irregulares.

Por el contrario, podría tener una única página del lado del servidor que ejecute y devuelva un esqueleto HTML, así como los datos (incluidos en JSON en la página) para representar los informes. Conexión única y más grande, pero menos golpes en el servidor web en total porque no está manejando 4 solicitudes y girando 4 tuberías, etc.


1
¿Puede dar un ejemplo de una pequeña solicitud que necesitaría en AJAX que de otro modo no necesitaría?
jhocking

1
Claro, ¿alguna vez notaste cómo, en este sitio, puede decirte si alguien ya respondió una pregunta? Eso se logra a través de una pequeña solicitud ajax. . .
Wyatt Barnett

@WyattBarnett AJAX no necesariamente significa encuestas. Simplemente puede reemplazar cargas de página completa con cargas de página parciales. En muchos casos, puede aumentar la carga del servidor, pero no creo que sea cierto en "la mayoría de los casos".
Davy8

hm, bueno, ese ejemplo me parece más algo que puedes hacer en AJAX que no puedes hacer de otra manera, en lugar de algo que requiere más solicitudes de servidor que de otra manera. Supongo que el OP no estaba claro si se refería a "más rendimiento al hacer exactamente lo mismo" o si se refería a "más rendimiento al aprovechar al máximo AJAX"
jhocking

1
Tenga en cuenta que el sondeo / sondeo largo es un mero subconjunto de AJAX (como se indica aquí), también conocido como "cometa" . Websockets, que permiten la inserción "verdadera" libre de sondeo o AJAX del lado del servidor (iniciado por el servidor) reducirá en gran medida el desperdicio de recursos requerido para este tipo de característica.
Alan H.

2

Si está utilizando AJAX para reemplazar el trabajo que el servidor estaría haciendo, sí, eso mejorará el rendimiento del servidor. Sin embargo, es posible que haya diseñado cosas para que el servidor siga haciendo lo mismo y ahora lo que sea que esté sucediendo con AJAX esté por encima de lo que el servidor ya estaba haciendo.

Principalmente se trata de cosas de la interfaz de usuario, ya que no debería hacer nada más en el lado del cliente. Básicamente, todo lo que el servidor estaba haciendo para admitir la interfaz de usuario (por ejemplo, volver a cargar la página con un diseño diferente en respuesta a la entrada del usuario) lo hace con JavaScript.


0

Si la representación HTML es una gran parte del perfil de rendimiento de su servidor de aplicaciones, mover la representación HTML al cliente puede ser una ganancia de rendimiento en el servidor de aplicaciones.

Sin embargo, si la representación HTML es una pequeña parte del perfil de rendimiento de su servidor de aplicaciones, más solicitudes típicamente significarán más viajes a través de la pila, más consultas, más de todo en el servidor de aplicaciones, una pérdida de rendimiento.

Por supuesto, la única forma de saber en su caso particular es probarlo.


1
Tengo problemas para pensar en algún ejemplo en el que usar AJAX cause más solicitudes que hacer lo mismo sin AJAX. ¿Puede dar un ejemplo?
jhocking

1
HTML siempre se representa en el lado del cliente.
Jonas

1
Presumiblemente, habló mal y quiso decir "manipulación" y no "renderizado"
jhocking

Comenzando desde la vista / plantilla, combinándola con variables y renderizando HTML sin formato a partir de ella.
yfeldblum

AJAX causaría más solicitudes que hacer lo mismo sin AJAX en casos como: su diseño principal tiene "agujeros" pero se entrega con esos agujeros al navegador, y esos agujeros se "llenan" con AJAX. Ver, por ejemplo, Facebook.
yfeldblum

0

Debe considerar la mejor manera de implementar su solución. Una forma simple no dinámica no necesita ajax y agregarla puede dañar el rendimiento. Si su problema son malas consultas, toda la optimización de ajax en el mundo no le dará un aumento de rendimiento que será aceptable.

Si su servidor está sobrecargado de trabajo, debe averiguar por qué.

Si está recibiendo muchos golpes, entonces ajax no va a solucionar ese problema, necesita más capacidad. Agregar ajax solo aumentará la cantidad de solicitudes que su servidor debe manejar.

Si tiene una página complicada, debería ver si hay algo que pueda hacer del lado del cliente para reducir la carga en su servidor. Si su página es dinámica pero realmente tiene un paquete de datos en caché limitado que para el ajuste del lado del cliente puede dar mejores resultados.

Y algunas veces Ajax ayudará. Cuando tiene formularios complejos con datos dinámicos, ajax gana el día. Pero si sus consultas son complicadas y demoran mucho tiempo en ejecutarse, entonces ajax aún no resolverá su problema.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.