Solicitud
También conocido como sampler
Una solicitud HTTP es la unidad de trabajo "más pequeña" que puedes definir para que una prueba realice. Generalmente, al probar ArcGIS Enterprise, puede ser una URL para un recurso como un servicio de mapas, servicio de entidades o resolución de rutas, pero también puede ser una llamada para un objeto estático como un archivo *.css o *.js.
El protocolo puede ser HTTP (texto plano) o HTTPS (seguro) y el método puede ser uno de muchos, aunque GET POST y HEAD son típicamente los más comunes.
Una solicitud dinámica de servicio de mapas se parecería a la siguiente forma:
https://yourwebadaptor.domain.com/server/rest/services/NaturalEarth/MapServer/export?bbox=-130.9656801129776%2C18.608785315857112%2C-57.52504741730332%2C52.34557596043248&bboxSR=4326&imageSR=4326&size=1920%2C882&dpi=96&format=png32&transparent=true&layers=show%3A15%2C16%2C17%2C19%2C20%2C21%2C22%2C23%2C24%2C25%2C26%2C27%2C28%2C29%2C30%2C31%2C32%2C33%2C34%2C35&f=image
La misma URL como una solicitud HTTP de Apache JMeter:
Cómo se vería una solicitud estática:
https://yourwebadaptor.domain.com/portal/home/10.9.0/js/jsapi/dojo/dojo.js
Apache JMeter también hace la distinción entre una solicitud y un sampler, aunque ambos definen una acción a realizar. Un sampler, sería la ejecución de un proceso a nivel del Sistema Operativo que realiza algún tipo de acción como ejecutar una herramienta de geoprocesamiento para crear una geodatabase de archivos o crear una nueva versión SDE en una geodatabase empresarial. Cada prueba debe tener al menos una solicitud o sampler.
Otro tipo de sampler es un web socket. Aunque es similar a una solicitud HTTP en que realiza una llamada a través de la "web" y puede estar asegurado, utiliza un protocolo diferente para comunicarse con el servidor remoto así como diferentes parámetros para especificar opciones de parámetros.
Transacción
Una transacción es un agrupamiento lógico de una o más solicitudes http. Las solicitudes pueden ser dinámicas y/o estáticas. Juntas, estas solicitudes típicamente constituyen una operación de usuario, por ejemplo:
- La carga de la aplicación web
- Una acción de navegación como panorámica o zoom
- Una función de búsqueda
- Creación de una nueva Versión SDE dentro de una GeoDatabase Empresarial
No es un requisito técnico usar transacciones en una prueba, pero hacerlo puede mejorar mucho el análisis ya que las operaciones individuales (por ejemplo, transacciones) podrían aislarse para mostrar sus respectivos comportamientos de rendimiento durante la ejecución. Esto puede ser muy informativo.
Entender que solo las solicitudes para escala del mapa 1:72,224 tuvieron problemas de rendimiento es muy útil desde la perspectiva del ajuste ya que sabrías exactamente qué áreas del documento o proyecto del mapa necesitarían
ajustarse... las transacciones pueden ayudarte a lograr esto.
Transacción Apache JMeter que contiene tres solicitudes de una operación:
Prueba
También conocido como plan de prueba o proyecto de prueba
El término "prueba" es bastante genérico y a menudo se usa tanto como sustantivo (Creé una prueba para llamar al recurso) como verbo (Voy a probar el servicio). Las transacciones y solicitudes usualmente se definen en una prueba. La prueba tendrá opciones adicionales para configurar tales como: cuánto tiempo durará la prueba, dónde van los resultados, si se deben recopilar métricas en los servidores remotos.
Diferentes frameworks usan terminología ligeramente diferente para describir una prueba. En el caso de Apache JMeter, una prueba o proyecto de prueba se llama Plan de Prueba y se designa con una extensión de archivo *.jmx.
Carga escalonada
También conocida como carga
La carga escalonada es una característica que define cuánto tiempo y cuántos hilos concurrentes aplicar durante la prueba mediante presión incremental uniforme (por ejemplo, similar a una escalera). Configurar la prueba para una carga escalonada es útil para entender cómo funciona o escala un servicio de mapas o cómo se comportan los recursos del despliegue
a medida que se lanzan más y más solicitudes. La presión definida también puede disminuir (hacia el final de la prueba) pero no es obligatorio.
Grupo de Hilos Apache JMeter (bzm - Concurrency) especificando y visualizando una carga escalonada específica:
Carga constante
Una carga constante también define cuánto tiempo y cuántos hilos aplicar pero usualmente se establece para un ritmo constante durante largos períodos. En lugar de enfocarse en rendimiento y escalabilidad esta configuración es típicamente para entender durabilidad y estabilidad.
Grupo de Hilos Apache JMeter (bzm - Concurrency) especificando y visualizando una carga constante específica:
Hilos de prueba
También conocidos como threads
Este es el mecanismo responsable por aplicar carga tomando el trabajo definido a realizar en la prueba tales como las transacciones y/o solicitudes y ejecutándolos repetidamente.
Los hilos de prueba típicamente se comportan en forma serial donde cada hilo comienza leyendo la primera solicitud definida en la prueba, la envía al servidor y luego espera su respuesta. La siguiente solicitud en la prueba no será emitida hasta que llegue una respuesta del servidor o haya transcurrido un tiempo límite. Una vez que se cumple alguna de estas condiciones pasa a la siguiente solicitud. La mayoría de las pruebas están configuradas para que cada hilo repita este proceso continuamente durante toda la ejecución.
Varias tecnologías suelen referirse a los hilos de prueba como usuarios virtuales pero esto puede ser engañoso. Los hilos de prueba son solo el medio (presión) para un fin (rendimiento entregado).
En otras palabras, la ejecución de una prueba configurada con carga escalonada que alcanza los 100 hilos no significa que el entorno esté soportando 100 usuarios virtuales concurrentes. En este caso, determinar usuarios se calcularía según el rendimiento del test; transacciones/segundo, por ejemplo.
Grupo de Hilos Apache JMeter (bzm - Concurrency) definiendo la carga escalonada vía hilos (de prueba):
Usuarios
También conocidos como usuarios virtuales
El número de usuarios soportados es uno de los ítems más solicitados para determinar a partir de una prueba de carga y usualmente toma la forma de:
- ¿Cuántos usuarios soportará este servicio o aplicación específica?
- ¿Soportará un servicio o aplicación particular al menos X usuarios?
El cálculo de usuarios está estrechamente ligado al tiempo muerto así como a artefactos medidos en la prueba tales como rendimiento y tiempo de respuesta.
Usar Little Law con estas entradas puede proporcionar una estimación teórica del número de usuarios que un entorno puede soportar.<\/P>
Tiempo de Pensamiento<\/STRONG>
También conocido como ritmo de flujo de trabajo<\/STRONG><\/EM><\/H5>El tiempo de pensamiento es una duración (definida en segundos o milisegundos) que se añade a una prueba para simular los retrasos del comportamiento humano que ocurrirían cuando una persona interactúa naturalmente con el servicio de mapas o la aplicación web.
Se pueden añadir retrasos de tiempo de pensamiento a transacciones (por ejemplo, una operación) o solicitudes o incluso a la prueba misma (lo que se denomina ritmo de flujo de trabajo). La forma en que se añaden puede variar según el marco de pruebas involucrado.
En el caso de Apache JMeter, hay varios temporizadores diferentes disponibles que se pueden añadir a la prueba para simular varios tipos de retrasos.<\/P>Indicadores Clave de Rendimiento (KPIs)<\/STRONG><\/H5>Los KPIs son métricas de prueba que ayudan con el análisis de una prueba de carga. Algunos de los más populares están asociados con medir el tiempo de respuesta y el rendimiento de la prueba. Sin embargo, también se extienden a elementos que cuentan el número de solicitudes fallidas, cuentan la longitud promedio del contenido (por solicitud) o recopilan información sobre la utilización del hardware (como CPU, memoria, red y disco).
Aunque la capacidad para capturar la utilización del hardware a menudo requiere configuración adicional de la prueba y permisos dentro del entorno, esta información es uno de los artefactos más importantes capturados en una prueba de carga.<\/P>Nota: La utilización capturada del hardware es uno de los artefactos más importantes capturados en una prueba de carga.<\/FONT><\/STRONG><\/P>Tiempo de Respuesta<\/STRONG><\/H5>El tiempo de respuesta es una métrica común que se usa para medir el rendimiento de una solicitud, transacción o prueba. En pocas palabras, proporciona una comprensión sobre qué tan rápido se está comportando una operación.
El valor generalmente se presenta en segundos o milisegundos. Un rendimiento más rápido significa tiempos de respuesta más bajos, lo que se traduce en una experiencia de usuario más favorable. El tiempo de respuesta puede graficarse durante la duración de la prueba para entender cómo escaló el rendimiento o listarse junto con el rendimiento para un punto particular en la prueba (por ejemplo, donde el rendimiento alcanzó su pico).<\/P>Nota: Los tiempos de respuesta son uno de los artefactos más importantes capturados en una prueba de carga.<\/STRONG><\/FONT><\/P>Idealmente, el rendimiento del elemento probado seguirá la siguiente curva donde los tiempos de respuesta aumentarán más rápidamente (alrededor del punto del pico máximo). En el siguiente ejemplo, el tiempo promedio de respuesta por solicitud en el pico máximo fue aproximadamente 0.4 segundos.<\/P>
<\/span><\/P>Rendimiento<\/STRONG>:<\/H5>El rendimiento es una métrica común que se usa para medir la escalabilidad de un servicio de mapas, aplicación web o infraestructura hardware. Esencialmente, proporciona una comprensión sobre la tasa a la cual se puede realizar una operación durante un período determinado.
El valor generalmente puede capturarse como solicitudes\/segundo, transacciones\/segundo (por ejemplo, operaciones\/segundo) o pruebas\/segundo, aunque a menudo se expresa durante la duración de una hora (la tasa en segundos multiplicada por 3600).
Una mayor escalabilidad significa más rendimiento, lo que se traduce en soporte para más usuarios.
Algunos análisis de pruebas se centran en el rendimiento promedio de todas las transacciones para una prueba, mientras que otros podrían examinar el rendimiento promedio para cada operación individual.<\/P>Nota: El rendimiento es uno de los artefactos más importantes capturados en una prueba de carga.<\/STRONG><\/FONT><\/P>Idealmente, el rendimiento del elemento probado se parecerá a la siguiente curva donde alcanza un pico y luego se estabiliza. <\/SPAN>Cuando el rendimiento alcanza su pico y\/?o se estabiliza sugiere que la prueba ha encontrado algún tipo de cuello de botella. En el siguiente ejemplo, el rendimiento promedio por solicitud en el pico fue aproximadamente 24 solicitudes por segundo (o 86,400 solicitudes por hora).<\/P>
<\/span><\/P>Cuello de Botella<\/STRONG><\/H5>Un cuello de botella es una condición en un despliegue donde uno de sus componentes o niveles limita la tasa a la cual puede responder a las solicitudes entrantes. Un cuello de botella puede tomar la forma de:<\/P>Ejemplos HardwareTodos los núcleos CPU del ArcGIS Server están completamente utilizados<\/LI>La memoria disponible está agotada<\/LI>La entrada/salida del disco almacenamiento del servidor BaseDatos está completamente utilizada<\/LI>La tarjeta red está saturadaDebido al tráfico Enviado o Recibido <\/LI><\/UL><\/LI><\/UL><\/LI>Ejemplos SoftwareLa base datos fue configurada para permitir solo 25 conexiones actuales a pesar tener recursos hardware amplios disponibles<\/LI>El rendimiento para consumir un servicio mapas se estabiliza pero la utilización CPU del ArcGIS Server no aumenta por encima del 25%<\/LI><\/UL><\/LI><\/UL>Siempre existirá un cuello botella en un despliegue y determinar qué componente restringe primero es parte del análisis. A menudo será necesaria una prueba carga para exponer dónde ocurrirá el primer cuello botella ya que solo puede observarse bajo gran presión. Mientras que los recursos y configuraciones servidor suelen ser foco del análisis cuello botella, los recursos cliente prueba (CPU, memoria, red, disco y en algunos casos la licencia testing) también pueden ser factor. Alcanzar un cuello botella no es necesariamente problema, solo indica dónde está la primera debilidad o limitación dentro sistema. A veces un cuello botella es considerado algo "bueno", por ejemplo ejecutando un proceso ArcGIS caching grande, se desea que CPU sea primer cuello botella porque está haciendo trabajo crear las teselas mapa. Si CPU solo puede alcanzar 50% debido otro cuello botella (p.ej., disco I\/?O), tomará doble tiempo terminar trabajo relativo a utilización CPU al 100%.<\/P>Nota: Siempre existe un cuello botella en un despliegue<\/STRONG><\/FONT><\/P>Tipo Prueba<\/STRONG>
También conocido como performance test, load test, stress test, endurance test, benchmark test<\/STRONG><\/EM><\/H5>Muchas organizaciones suelen usar diferentes categorías para clasificar las pruebas realizadas.<\/P>Un performance test típicamente se utiliza para solucionar problemas con un servicio o aplicación cuando está funcionando lentamente o produce tiempos respuesta mayores a lo esperado. No necesitan involucrar una carga escalonada y podrían ejecutarse convenientemente como un solo usuario interactuando directamente desde un navegador web con el endpoint interesado.<\/P>Un load test a menudo puede usarse para describir una prueba carga escalonada con objetivo cumplir un throughput y tiempo respuesta particular. Por ejemplo, X transactions\/?sec<\/EM> con tiempo respuesta menor a Y seconds<\/EM> y sin fallas. Esto podría resultar en agotamiento uno recursos hardware servidor pero usualmente no es objetivo. Un load test también puede denominarse como scalability test.<\/P>Un stress test es similar pero frecuentemente enfocado en alcanzar presión múltiplo objetivo load test. En otras palabras, si load test intentaba alcanzar X transactions\/?sec<\/EM>, stress test podría intentar alcanzar X * 5 transactions\/?sec<\/EM> sin encontrar cantidad significativa fallas.<\/P>Un endurance test tiene distinción de intentar romper<\/EM> componentes sistema. Su carga aplicada puede ser múltiplo stress test donde objetivo es<\/EM> encontrar errores significativos y observar throughput y tiempo respuesta cuando ocurren. Un endurance test también puede denominarse durability test donde carga aplicada es constante por duración muy larga y patrones utilización hardware y recuperación son observados.<\/P>Plan Prueba<\/STRONG><\/H5>En sentido general, un plan prueba es documento, tabla o lista que define las pruebas específicas que se ejecutarán así como sus respectivos objetivos. Estos objetivos son la razón y el propósito de cada prueba. El análisis de los resultados (a mano o a partir de informes de prueba generados) debería ayudarte a determinar si se lograron o no los objetivos de cada prueba.<\/P>Testing Framework <\/STRONG><\/H5>El testing framework es la herramienta o tecnología utilizada en forma de bibliotecas, APIs así como una interfaz gráfica de usuario (GUI) para ensamblar solicitudes, y la prueba además de definir la carga a aplicar.
Existen muchos excelentes testing frameworks y Apache JMeter es solo uno<\/EM> de ellos. Aunque todos tienen un propósito similar, muchos adoptan diferentes enfoques respecto al vocabulario de ciertos componentes y cómo crean una prueba y aplican carga. Algunos ponen la definición de las solicitudes y transacciones en sus propios archivos con la configuración de carga por pasos en otro.
Con Apache JMeter, todos los objetos de prueba se definen en el Plan de Pruebas y están lógicamente separados dentro del árbol.<\/P>Algunos ejemplos de testing frameworks para carga:<\/P>Apache JMeter<\/A> <\/LI>LoadRunner<\/A> <\/LI>Silk Performer<\/A> <\/LI><\/UL>Algunos ejemplos de testing frameworks para rendimiento:<\/P>
wget<\/A>- Una herramienta de línea de comandos para recuperar una o más URLs<\/LI>
- Puede proporcionar un alto nivel de detalle en cada solicitud y respuesta<\/LI><\/UL><\/LI>
curl<\/A>
- Una herramienta de línea de comandos para recuperar una o más URLs<\/LI>
- Puede proporcionar un alto nivel de detalle en cada solicitud y respuesta<\/LI><\/UL><\/LI>
Fiddler<\/A>- Depurador HTTP basado en GUI que puede usarse solo o con un navegador web<\/LI>
- Puede proporcionar un alto nivel de detalle en cada solicitud y respuesta<\/LI><\/UL><\/LI><\/UL>
Testing Framework Architecture<\/STRONG><\/H5>Al probar ArcGIS Enterprise, la mayor parte de la atención arquitectónica se centra en la escalabilidad de los niveles del despliegue: Load Balancer, Web Adaptor, Portal for ArcGIS, ArcGIS DataStore, ArcGIS Server, Enterprise Geodatabase y Network Storage. Mientras que una máquina de prueba con 8 núcleos generalmente puede enviar una cantidad considerable de solicitudes que satisfacen la prueba típica, a veces se necesitan múltiples máquinas si la carga a aplicar requiere gran potencia.<\/P>Dependiendo del testing framework involucrado, varios componentes de prueba pueden separarse en diferentes máquinas para mejorar la escalabilidad del test client<\/EM>.<\/P>Los componentes comunes para escalar son:<\/P>Test ControllerComo su nombre indica, el enfoque principal del controller es detener e iniciar la prueba así como coordinar la recopilación de métricas de prueba desde uno o más Test Agents<\/LI>En el caso de Apache JMeter, el controller está integrado directamente en la GUI pero también se ejecuta cuando la prueba se ejecuta desde la línea de comandosOtros testing frameworks pueden tener un frontend web-based Test Controller<\/LI><\/UL><\/LI>Típicamente, solo se necesita un Test Controller para cualquier entorno de prueba dado, pero puede ejecutarse en hardware dedicado separado de los Test Agents<\/LI><\/UL><\/LI>Test AgentLa función principal del Test Agent es enviar solicitudes y recibir respuestas del servidorEste componente realiza la mayor parte del trabajo y requeriría la mayoría de los recursos CPU<\/LI><\/UL><\/LI>Para trabajos grandes, podrían necesitarse múltiples máquinas Test Agents<\/LI>En el caso de Apache JMeter, por defecto, el Test Agent se ejecuta en la misma máquina que el Test Controller <\/LI><\/UL><\/LI>Test RepositoryUna máquina dedicada a almacenar los resultados del load test Esto puede incluir métricas como tiempo de respuesta, rendimiento y utilización del hardware<\/LI><\/UL><\/LI>En el caso de Apache JMeter, los resultados se almacenan en el controller en archivos texto (*.JTL)Es posible enviar los resultados a una base de datos, pero esta no es la configuración predeterminada<\/LI><\/UL><\/LI><\/UL><\/LI>Test VisualizationUna máquina usada para visualizar las métricas del test y utilización del hardware en tiempo real<\/LI>En el caso de Apache JMeter, no se recomienda usar la GUI para visualización de datos durante una ejecución productiva sino la línea de comandos síSi los resultados se envían a una base de datos, software adicional puede conectarse al Test Repository para visualizar la información<\/LI><\/UL><\/LI><\/UL><\/LI><\/UL>Ley del Tiempo de Respuesta Interactivo<\/STRONG><\/H5>La Ley del Tiempo de Respuesta Interactivo es una fórmula que define la relación entre factores clave del rendimiento, a saber usuarios, rendimiento (throughput), tiempo de respuesta y tiempo muerto (user think time). El cálculo puede organizarse para determinar el parámetro que interese siempre que conozcas los otros tres. Por ejemplo, si se conoce el número de usuarios que utilizan el sistema, cuál es el tiempo promedio de respuesta para las solicitudes y el tiempo promedio muerto del usuario, entonces podemos derivar la demanda estimada del throughput sobre el sistema. Esta ley es muy útil al intentar convertir usuarios a throughput y throughput a usuarios y otros casos similares además es fundamental para áreas relacionadas con pruebas como planificación de capacidad.<\/P>Dada la siguiente fórmula:
N = X * (R + Z)<\/P>N = Número de trabajos o usuarios concurrentes
X = Throughput por segundo en el sistema
R = Tiempo de respuesta, o tiempo promedio que un trabajo pasa en el sistema
Z = Tiempo muerto (Think time)<\/P>Para más información sobre la Ley del Tiempo de Respuesta Interactivo vea:<\/P>http:\/\downloads.esri.com\Support\downloads\other_\ArcGIS%20Enterprise%20deployment%20guide_Scene%20layer%20benchmark%20testing.pdf<\/A>https:\/\homepages.inf.ed.ac.uk\jeh\biss2013\Note2.pdf<\/A> <\/P>
<\/P>
Apache JMeter<\/A> lanzado bajo la <\/SPAN>Apache<\/A> <\\/SPAN?>Licencia 2.0.<\\/A?> Apache, Apache JMeter, JMeter, la pluma Apache y el logo Apache JMeter son marcas registradas de Apache Software Foundation.<\\/SPAN?><\\/P>
