Informe de muestra de CloudTest | Akamai...degradarse, con el tiempo, ya sea debido a las tasas de error, al aumento de la simultaneidad, a problemas de la base de datos o a la "transacción

1Informe de síntesis de CloudTest

Le mostramos un ejemplo típico del

informe personalizado de una prueba de carga

elaborado por el equipo de ingenieros

de rendimiento de Akamai

Informe de síntesis de CloudTest


Contenido

Resumen ejecutivo ....................................................................................................................................................3

Introducción ...............................................................................................................................................................3

Objetivos.....................................................................................................................................................................3

Escenarios de prueba ...............................................................................................................................................3

Resultados ..................................................................................................................................................................3

Qué hemos aprendido ..............................................................................................................................................3

Recomendaciones .....................................................................................................................................................4

Conclusiones ..............................................................................................................................................................4

Resultados de la prueba ...........................................................................................................................................5

Resultados a partir de fecha/hora ...........................................................................................................................5

Resumen de los resultados.......................................................................................................................................5

Análisis del tiempo de respuesta ............................................................................................................................6

Análisis de las transacciones ....................................................................................................................................7

Errores .......................................................................................................................................................................13

Análisis de la velocidad de envío o el índice de visitas ......................................................................................14

Análisis del ancho de banda ..................................................................................................................................15

Análisis de los subelementos .................................................................................................................................16

Análisis completo de los errores ...........................................................................................................................17

Acerca de Akamai ....................................................................................................................................................19


Resumen ejecutivo

INTRODUCCIÓN

En este documento se presentan los resultados de las pruebas realizadas para "Cliente" en el entorno de producción actual. Se han anonimizado los dominios de "Cliente" y demás detalles que puedan vincularse a este. Estas pruebas se llevaron a cabo en la plataforma Akamai CloudTest.

OBJETIVOS

La prueba se diseñó para medir el rendimiento y la escalabilidad del sistema, así como para supervisar las métricas de tiempo de respuesta a medida que aumentaba la simultaneidad de usuarios a lo largo del tiempo. Esto incluye:

• Determinar la escalabilidad y el rendimiento del sistema al aumentar la simultaneidad de usuarios a lo largo del tiempo.

• Determinar los tiempos de respuesta del sistema al aumentar la simultaneidad de usuarios a lo largo del tiempo.

• Medir el impacto que tienen los picos de carga comerciales en el rendimiento del sistema en condiciones de carga máxima.

ESCENARIOS DE PRUEBAS

Se crearon nueve escenarios de pruebas:

1) Escenario 1: 46 % de carga 6) Escenario 6: 33,3 % de pico 2) Escenario 2: 24 % de carga 7) Escenario 7: 3000 usuarios 3) Escenario 3: 13 % de carga 8) Escenario 8: 66,6 % de pico 4) Escenario 4: 17 % de carga 9) Escenario 9: 33,3 % de pico 5) Escenario 5: 66,6 % de pico

Asimismo, se añadieron otros escenarios a esta composición para un pico comercial secundario. El objetivo de esto era iniciar el primer pico comercial, alcanzar el nivel máximo de tráfico y, a continuación, iniciar otro pico comercial mientras el primero aún descendía. Con este nuevo escenario, se pretendía imitar el comportamiento observado durante el "evento".

Resultados

QUÉ HEMOS APRENDIDO

• La carga no es capaz de adaptarse bien a la carga base máxima sin degradarse el rendimiento.

• La mayoría de los problemas se produjeron en el dominio xxxxxx, junto con dos dominios xxxxxx.

• La mayoría de los errores fueron de tipo HTTP 504, 502, 404 y 400.


• La "transacción X" tuvo, con diferencia, la mayor medida del percentil 90, al tardar 49,194 segundos.

• Dos llamadas xxxxxx a un dominio de desarrollo fueron la segunda y la tercera más largas del percentil 90.

• Los índices de transacción y los tiempos de respuesta se degradaban uniformemente a medida que progresaba la ejecución de la prueba.

RECOMENDACIONES

• Determinar la causa de la degradación en la "transacción X".

• Decidir si el dominio xxxxxx de desarrollo debe incluirse en los recursos y la ejecución de la prueba.

• Reducir las anotaciones del sistema para mejorar el rendimiento de varios paneles de control; esto solo es necesario cuando los servidores están inactivos.

• Determinar la causa principal de la reducción de los índices de transacción (concretamente, xxxxxx) al ejecutarse los picos comerciales.

CONCLUSIONES

El tiempo de respuesta se degradaba continuamente a partir de los xx xxx usuarios a medida que aumentaba la simultaneidad, pero se estabilizaba una vez alcanzados los xx xxx usuarios. Durante el resto de la prueba, el tiempo medio de respuesta aumentaba cada vez que se introducía un pico comercial en el sistema, pero se recuperaba a medida que los usuarios comerciales volvían a bajar hasta la simultaneidad media.

Los aumentos significativos de los errores coincidieron con los picos comerciales. Se correspondían, principalmente, a los errores HTTP 504 (Tiempo de espera agotado para la puerta de enlace), HTTP 502 (Puerta de enlace no válida), HTTP 404 (No encontrado) y HTTP 400 (Solicitud errónea), produciéndose la mayoría de ellos en los dominios xxxxxx y xxxxxx. Estos errores pueden atribuirse a diferencias en el hardware de los siete servidores web integrados. Tres de los servidores tenían hardware más antiguo, con menos capacidad de carga (en términos de CPU y memoria) que los otros cuatro. El balanceador de carga, al no detectar esta diferencia, continuó distribuyendo la carga por igual, por lo que sobrecargó esos servidores.

Dos dominios (XXXX y XXXX), cada uno de los cuales atendía solicitudes de un solo recurso, fueron los más lentos en términos de tiempo de respuesta. Aunque estos dominios atendían un porcentaje muy pequeño del total de solicitudes, podría deducirse que las solicitudes de recursos de terceros pueden afectar negativamente al rendimiento de ciertas páginas.

El objetivo de la prueba era identificar cómo reacciona el sitio de producción existente cuando hay presente una gran base de usuarios simultáneamente en el sistema y se agregan rápidamente tipos específicos de usuarios a la configuración. Se emplearon niveles de picos comerciales diversos para determinar la estabilidad y la escalabilidad de la configuración. Los índices de transacción parecen degradarse, con el tiempo, ya sea debido a las tasas de error, al aumento de la simultaneidad, a problemas de la base de datos o a la "transacción X".


Resultados de la prueba

RESULTADOS A PARTIR DE FECHA/HORA

Fecha/hora de inicio de la prueba: 17/04/2018, 05:16:59 hrs

Fecha/hora de finalización de la prueba: 17/04/2018, 07:35:15 hrs

Duración de la prueba: 02:18:10,62

Descripción: Prueba de rendimiento de la infraestructura de producción de "Cliente"

RESUMEN DE LOS RESULTADOS

Datos fundamentales y métricas de alto nivel de esta prueba:

• Solicitudes HTTP enviadas: 193 800 623

• Errores de solicitud HTTP: 350 504 (0,181 %)

• Tiempo de respuesta medio: 222 ms

• Tiempo de respuesta máximo: 278 368 ms

• Total de bytes enviados: 520,7 GB

• Total de bytes recibidos: 2,1 TB

• Capacidad efectiva (solicitudes/segundo): 23 398 mens/s

• Capacidad efectiva (bits/segundo): 2 543 365 201 bits/s

Los usuarios virtuales de esta prueba se generaron con la siguiente distribución geográfica:

Usuarios virtuales por ubicación


ANÁLISIS DEL TIEMPO DE RESPUESTA

Una de las principales métricas de una prueba de carga es el tiempo medio de respuesta. Los tiempos de respuesta medios dan una idea general del rendimiento de la aplicación bajo carga. Cuanto más horizontal sea la línea de tiempo de respuesta medio (a medida que aumenta la carga o el número de usuarios virtuales), mejor.

El gráfico de tiempo medio de respuesta que se muestra a continuación es una media de todas las solicitudes HTTP realizadas durante la prueba. El tiempo de respuesta medio comenzó a degradarse con casi xx xxx usuarios, y siguió la tendencia hasta que se alcanzaron los xx xxx usuarios simultáneos. Después, los tiempos de respuesta solo aumentaron cuando se sometía al sistema a picos comerciales, pero se recuperaban después de estos picos.

Cuando se identifican variaciones en los tiempos de respuesta, es importante identificar los dominios asociados. En el gráfico siguiente, se pueden ver los tiempos de respuesta medios separados por dominio a lo largo del tiempo. Los dominios XXXX y XXXX representan los tiempos de respuesta más prolongados que se muestran, pero se corresponden mayormente a picos comerciales.

Usuarios virtuales frente a duración media de recopilación



ANÁLISIS DE LAS TRANSACCIONES

Las transacciones representan una agrupación de subelementos (solicitudes HTTP, scripts, tiempo de procesamiento, etc.). La mayoría de las pruebas utilizan transacciones para representar de forma precisa los tiempos de carga de página reales que experimentaría un usuario final. Lo ideal es que el tiempo de finalización de la transacción de cada subelemento permanezca fijo durante toda la prueba. En este caso concreto, los tiempos de respuesta se mantuvieron muy estables, y cualquier aumento apreciable parece coincidir con el aumento de los picos de simultaneidad de usuarios que se introdujeron en diversos intervalos.

En la siguiente tabla, se muestran las medidas de percentil 95 de toda la prueba.

El widget de análisis de recopilación de las páginas siguientes identifica cada una de las transacciones utilizadas en la composición de la prueba y las estadísticas asociadas a cada subelemento.


Usuarios virtuales frente a percentil 95 de duración de recopilación


RecopilaciónRecopilaciones completadas

Duración mediaDesviación

estándarPercentil 90

Escenario1.01: Página de inicio 112 302 1,089 1,204 1,473

Escenario1.02: TransacciónX 27 939 0,65 0,472 1,04


















Escenario1.10: TransacciónX 5449 15,108 15,761 27,283







Escenario1.11-1: TransacciónX 147 896 0,323 0,583 0,531















Escenario1.12: TransacciónX 335 10 097 13,827 31,999






Escenario1.12a: TransacciónX 1 694 372 7,236 7,883 11,842

















































































































Escenario4.08: TransacciónX 1 013 309 0,345 0,69 0,486


Escenario4.09: TransacciónX 1 008 249 0,363 0,37 0,626
























































Escenario6.16: TransacciónX 284 8,219 10,629 25





Escenario6,99: TransacciónX 17 311 0,76 1,418 1,103


ERRORES

Los errores permiten identificar fácilmente dónde se hallan los problemas en una prueba. Pueden provocar errores los problemas de red, de infraestructura, de hardware y de aplicaciones, entre otras fuentes. En el apartado "Análisis completo de los errores" de las últimas páginas de este resultado, pueden encontrarse todos los detalles relativos a estos. El conjunto de errores de la prueba lo formaban principalmente agotamientos de tiempo de espera de conexión y errores HTTP 504, 502, 404 y 400. (Normalmente, los gráficos siguientes van acompañados de leyendas, pero se han eliminado de este informe para preservar el anonimato del cliente).

Recuento de errores

Recuento de errores frente a errores por tipo a lo largo del tiempo

Errores por tipo a lo largo del tiempo


ANÁLISIS DE LA VELOCIDAD DE ENVÍO O EL ÍNDICE DE VISITAS

Otra métrica importante en cualquier prueba de carga es la capacidad (es decir, la velocidad de envío o el índice de visitas) de la prueba. Mide cuántas solicitudes HTTP puede procesar desde cero la aplicación de destino en un intervalo determinado (p. ej., por segundo o por minuto). En una aplicación perfectamente escalable, la velocidad de envío aumenta en línea recta con el incremento de usuarios virtuales. La velocidad de envío aumentaba linealmente a medida que aumentaba la simultaneidad de usuarios virtuales, lo que indica que el rendimiento no suponía un problema en este momento. (Normalmente, los gráficos siguientes van acompañados de leyendas, pero se han eliminado de este informe para preservar el anonimato del cliente).

Del dominio XXXX procede la mayor parte de los datos de velocidad de envío que se muestran a continuación.

Usuarios virtuales frente a velocidad de envío

Errores por tipo a lo largo del tiempo


ANÁLISIS DEL ANCHO DE BANDA

El ancho de banda es un cuello de botella potencial que puede llegar a su límite muy rápido, sobre todo si una aplicación tiene descargas de alto volumen o una gran cantidad de recursos de página, o si no emplea correctamente una CDN. En el caso que nos ocupa, el ancho de banda no parece ser un problema en este momento. Esta métrica siempre debe revisarse después de cada prueba para verificar que no hay cambios que puedan haber causado un cuello de botella o una degradación. (Normalmente, los gráficos siguientes van acompañados de leyendas, pero se han eliminado de este informe para preservar el anonimato del cliente).

Consumo de ancho de banda

Consumo de ancho de banda por dominio


ANÁLISIS DE LOS SUBELEMENTOS

En el siguiente gráfico, se puede ver el tiempo de finalización de cada uno de los escenarios de usuario (casos de prueba) que se observaron en el transcurso de la prueba. Lo ideal es que el tiempo de finalización de cada subelemento permanezca fijo durante toda la prueba. (Normalmente, los gráficos siguientes van acompañados de leyendas, pero se han eliminado de este informe para preservar el anonimato del cliente).

En el siguiente gráfico, se muestra el número de subelementos que se completaron a lo largo de la prueba. Conviene tener en cuenta que la ejecución de la prueba incorporaba picos de tráfico, que se pueden ver reflejados con precisión en el gráfico en los momentos correspondientes.

El widget de análisis de subelementos de las páginas siguientes identifica cada uno de los subelementos utilizados en la composición de la prueba y las estadísticas asociadas a cada subelemento.

Subelemento completado

Duración de subelemento media


Análisis de subelemento

Jerarquía de componentes

Subelementos completados

Duración media

Duración máxima

Bytes enviados Bytes recibidos Errores

Composición 493 455 658,035 s 8187,244 s 401 348 098 380 1 732 113 725 029 113 723

Escenario 1 94 048 538,724 s 8001,404 s 131 190 717 498 311 124 204 116 17 857

Escenario 2 69 531 183,291 s 670,233 s 42 456 494 993 173 923 240 388 29 190

Escenario 3 159 430 309,675 s 639,730 s 30 531 767 971 319 869 928 469 35 400

Escenario 4 24 243 1264,178 s 8168,812 s 39 937 195 294 419 228 478 054 3670

Escenario 5 95 605 1264,259 s 8187,244 s 93 538 651 159 414 184 575 091 19 716

Escenario 6 4812 3919,446 s 8108,647 s 444 643 336 5 222 159 216 33

Escenario 7 45 786 907,517 s 8117,809 s 63 248 628 129 88 561 139 695 7857

ANÁLISIS COMPLETO DE LOS ERRORES

En la tabla siguiente, se muestra un desglose detallado del tipo de error y los mensajes asociados.

Error SolicitudesRecuento de

errores

193 968 161 337 620

DominioX 973 271 64 291

Restablecimiento de conexión (java.net.SocketException) 271

Se ha superado el tiempo de espera de conexión de 60 000 ms. 62 147

Se ha completado el envío, pero no se ha recibido ninguna respuesta dentro del límite de tiempo de espera de lectura de socket de 120 000 ms.

DominioX 1 049 386 23

Se ha superado el tiempo de espera de conexión de 60 000 ms. 15

HTTP 400 - Solicitud errónea 5

DominioX 295 788 37


DominioX 60 762 484 31 124



Error al procesar la transacción X 14


HTTP 403 - Prohibido 3135

HTTP 500 - Error interno del servidor 986

HTTP 502 - Puerta de enlace no válida 331

HTTP 503 - Servicio no disponible 17

HTTP 504 - Tiempo de espera agotado para la puerta de enlace 10 672



errores


67

Se ha completado el envío, pero la conexión se ha interrumpido antes de recibir la respuesta.

4

No se puede verificar el certificado de servidor SSL para el dominio X. (com.soasta.common.exceptions.CommonException)

8

No se puede establecer el valor de la propiedad. Compruebe si los eventos tienen propiedades específicas.

10 130

No se puede establecer el valor de la cuenta de propiedad. La respuesta JSON no es válida.

5185

DominioX 1980 32




DominioX 743 308 8


DominioX 38 695 1649



DominioX 5 317 556 93 871


Se ha superado el tiempo de espera de conexión de 60 000 ms. 92 016


1

Se ha completado el envío, pero la conexión se ha interrumpido antes de recibir la respuesta.

7

DominioX 124 785 689 146 581

Mensaje de error de validación personalizado 1 24


Mensaje de error de validación personalizado 3 14 016




HTTP 400 - Solicitud errónea 11 596

HTTP 401 – Sin autorización 5

HTTP 417 - Error de expectativa 1


HTTP 502 - Puerta de enlace no válida 10.319


HTTP 504 - Tiempo de espera agotado para la puerta de enlace 49 335


Akamai garantiza experiencias digitales seguras a las empresas más importantes del mundo. La plataforma perimetral inteligente de Akamai llega a todas partes, desde la empresa a la nube, lo que permite a nuestros clientes y a sus negocios ser rápidos, inteligentes y seguros. Las mejores marcas del mundo confían en Akamai para lograr su ventaja competitiva gracias a soluciones ágiles que permiten destapar todo el potencial de sus arquitecturas multinube. En Akamai mantenemos las decisiones, las aplicaciones y las experiencias más cerca de los usuarios que nadie; y los ataques y las amenazas, a raya. La cartera de soluciones de seguridad perimetral, rendimiento web y móvil, acceso empresarial y distribución de vídeo de Akamai está respaldada por un servicio de atención al cliente, análisis y una supervisión ininterrumpida durante todo el año sin precedentes. Para descubrir por qué las marcas más importantes del mundo confían en Akamai, visite www.akamai.com/es/es, blogs.akamai.com/es, o siga a @Akamai en Twitter. Puede encontrar los datos de contacto de todas nuestras oficinas en www.akamai.com/locations. Publicado en mayo de 2019.


errores

Error HTTP: 404 No encontrado 11 602




Se ha completado el envío, pero no se ha recibido ninguna respuesta dentro del límite de tiempo de espera de lectura de socket de 120 000 ms. 115

Se ha completado el envío, pero la conexión se ha interrumpido antes de recibir la respuesta. 2

No se puede verificar el certificado de servidor SSL para el dominio X. (com.soasta.common.exceptions.CommonException) 9

No se puede establecer el valor de la propiedad. Compruebe si los eventos tienen propiedades específicas. 7597

No se puede establecer el valor de la cuenta de propiedad. La respuesta JSON no es válida. 20

No se puede establecer el valor de la propiedad X. La respuesta JSON no es válida. 1




Empiece la prueba hoy

¿Quiere comprobar cómo se enfrentan a la carga sus sitios web y aplicaciones? Visite akamai.com/cloudtest para obtener más información.

Más información

https://www.akamai.com/es/es

https://blogs.akamai.com/es

http://twitter.com/Akamai

https://www.akamai.com/es/es/locations.jsp

https://www.akamai.com/es/es/products/performance/cloudtest.jsp/

https://www.akamai.com/es/es/products/performance/cloudtest.jsp/

Documents

Informe de muestra de CloudTest | Akamai...degradarse, con el tiempo, ya sea debido a las tasas de error, al aumento de la simultaneidad, a problemas de la base de datos o a la "transacción