Creación de una Prueba de Carga en Apache JMeter Contra un Servicio de Capa de Función Hospedado (Intermedio/Avanzado)

AaronLopez

¿Por qué probar un Hosted Feature Layer Service? <\/SPAN><\/H1>Artículos anteriores de la Comunidad sobre pruebas de rendimiento con Apache JMeter se centraron en ejercitar Map Services a través de la función de exportación. Sin embargo, Hosted (feature) layers<\/A> también son una capacidad popular de ArcGIS Enterprise y se usan ampliamente en implementaciones. Además, las consultas a estas capas se basan en un diseño de cuadrícula "repetido" que puede ayudar a proporcionar un mayor grado de escalabilidad sobre otras tecnologías de visualización. Combina esto con el renderizado del lado del cliente de los datos devueltos y es una situación en la que todos ganan.<\/P>

Dado que los hosted feature services son una tecnología de servicio probada y favorita, tiene sentido querer probar las consultas de features bajo carga para observar su escalabilidad de primera mano.<\/SPAN><\/P>

Desafíos en la prueba de Hosted Feature Layer Service<\/SPAN><\/H1>Comparado con probar la función de exportar mapa, probar consultas de Hosted Feature Layer Service es un desafío ya que las solicitudes son más complejas de lograr programáticamente. Un "pan" navegacional o un "zoom" en el navegador web produce varias consultas diferentes, cada una con su propia geometría. Para repetir este comportamiento, la prueba de carga construida <\/SPAN>no tendrá solo una solicitud para emitir sino muchas y en cantidad variable. Combina esto con el hecho de que cada solicitud de consulta en la transacción tendrá una geometría única y un maxAllowableOffset cambiante (dependiendo de la escala del mapa) y hay muchas piezas móviles para seguir.<\/SPAN><\/P>¿Cómo probar un Hosted Feature Service?<\/SPAN><\/H1>El conjunto de datos USGS Motor Vehicle Use Roads<\/SPAN><\/H2>La comprensión del proceso en este Artículo es más efectiva si los pasos pueden reproducirse. Pero esta repetibilidad requiere acceso al mismo conjunto de datos. El tamaño espacial de la fuente de datos también debe ser lo suficientemente grande para generar datos decentes para la prueba pero no tan grande como para que sea engorroso descargarlo.<\/SPAN><\/P>Ingrese en el Motor Vehicle Use Map: Roads<\/A> conjunto de datos feature layer en hub.arcgis.com. Los 179K registros polilínea de datos USGS Roads en WGS 1984 Web Mercator (Auxiliary_Sphere), equivalen a aproximadamente 200MB cuando están comprimidos. Se proporciona bajo la licencia Creative Commons (CC0)<\/A>.<\/SPAN><\/P>

• Vista de los datos Roads desde ArcGIS Pro:<\/SPAN><\/LI><\/UL><\/span><\/SPAN><\/P>Vista a gran escala con etiquetado habilitado:<\/LI><\/UL><\/span><\/SPAN><\/P>Estos datos serán publicados desde ArcGIS Pro a un hosted feature service en ArcGIS Enterprise o cargados directamente a través de Portal for ArcGIS.<\/SPAN><\/P>Para crear un servicio a partir de estos datos, vea 

Publicar hosted feature layers<\/A> en ArcGIS Enterprise<\/SPAN><\/LI><\/UL>

Generación de Datos para Prueba<\/SPAN><\/H2>Esta prueba requerirá algunos buenos datos para usar dentro del test JMeter.<\/P>Para abordar tal tarea, se recomienda altamente usar las excelentes Load Testing Tools<\/A>.<\/P>

La versión 1.2.2 añade nuevas capacidades como la herramienta "Generate Query Extents" que será una gran ayuda para generar datos para pruebas en feature service. <\/SPAN><\/P>Estos datos utilizan el diseño basado en cuadrícula que es lo que queremos. Con el enfoque basado en cuadrícula, se crean sobres para el área deseada detrás del escenario. Luego, estos sobres se convierten a los extents adecuados 512x512 para consulta. El número de consultas (para cada sobre inicial) variará según dónde caiga en la cuadrícula... esto imita el comportamiento del servicio en un navegador web.<\/SPAN><\/P>

Disponibilizando las Herramientas desde ArcGIS Pro<\/H3>Una vez que el proyecto load-testing-tools <\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/> ha sido descargado a su máquina, coloque la carpeta descomprimida en un directorio accesible o hecho accesible por ArcGIS Pro. Si ya tiene una versión previa instalada de Load Testing Tools, esta versión actualizada puede instalarse junto a ella (aunque con un nombre diferente para la carpeta) o reemplazar completamente la carpeta existente.<\\p>
Por ejemplo:<\\p>

Coloque la carpeta load-testing-tools en C:\Users\[username]\Documents\ArcGIS
Use Add Folder Connection desde Catalog en ArcGIS Pro para listar el contenido de este directorio:







La herramienta “Generate Query Extents” puede trabajar con el hosted feature service, una copia local de los datos o los datos dentro de una geodatabase empresarial.


Nota: La herramienta debería generar query extents desde cualquier dato pero requiere que el Sistema Coordenado Proyectado sea WGS 1984 Web Mercator Auxiliary_Sphere (WKID: 3857).<\\STRONG>
Seleccione un Área de Interés

Seleccione un área de interés del mapa donde generar los datos para prueba. En este ejemplo, los datos Roads se están viendo desde el Noroeste de Estados Unidos (cerca de las fronteras estatales entre Idaho y Montana). La escala seleccionada del mapa es 1:1,000,000.

Ejecute la herramienta Generate Query Extents

• 
  Correr la herramienta Generate Query Extents debería presentar entradas similares a las siguientes:

Ajuste las Entradas para la herramienta Generate Query Extents

Las entradas predeterminadas fueron ajustadas para reflejar lo siguiente:

• 
  Se eliminaron varios niveles menores y mayores de escala
• 
  Los niveles restantes son 12, 13 y 14 que corresponden a las escalas del mapa 144448, 72224 y 36112 respectivamente
  • 
    Aumentó el número de registros para estas escalas
  • 
    Nivel 14 puede omitirse dependiendo del lanzamiento de Load Testing Tools (si está ausente, por favor agregue este nivel manualmente)
• 
  La ubicación del archivo salida debe ser algo similar a:
  • C:\Users\username\Documents\ArcGIS\Projects\Catalog2\query_extents.csv
• Clic Run para ejecutar la herramienta

Nota: La duración para generar los datos depende de varios factores como el número diferente niveles escalares, número registros (por cada nivel) y escala actual del proyecto.

Nota: Generar datos usando otros conjuntos puede dictar necesidad usar diferentes niveles escalares basados en nivel detalle y densidad features.

Validando los Datos Generados para Prueba

Es buena práctica verificar visualmente los datos generados para prueba. Esto permite al tester saber qué solicitará espacialmente la prueba al feature service. 

Una vez que la herramienta haya completado exitosamente generará 3 conjuntos principales de datos que son de interés:<\/P>

• Clases de entidades de cuadro delimitador
  • Contiene áreas de interés generadas aleatoriamente<\/LI>
  • Una clase de entidad para cada Nivel de Escala solicitado<\/LI><\/UL><\/LI>
  • Clases de entidades de Extensión de Consulta
    • Contiene una cuadrícula de mosaicos (512x512) en la que se basará cada consulta de entidad<\/LI>
    • Una clase de entidad para cada Nivel de Escala solicitado<\/LI><\/UL><\/LI>
    • Archivos CSV de Extensión de Consulta
      • Contiene los datos de prueba generados<\/LI>
      • Cada línea está compuesta por los componentes dinámicos de una solicitud al servicio de entidades<\/LI>
      • Un archivo para cada Nivel de Escala solicitado<\/LI><\/UL><\/LI><\/UL>

        <\/span><\/P>Desde el panel Catálogo, cargue la clase de entidad bbox_36112 en el mapa actual en ArcGIS ProEsta salida es muy similar a los datos de la herramienta Generate Bounding Boxes<\/LI><\/UL><\/LI>En este ejemplo, los cuadros generados aleatoriamente están en rosaEstas áreas representan la resolución de pantalla de un usuario que solicita datos del servicio de entidades<\/LI><\/UL><\/LI><\/UL><\/span><\/P>Ahora, desde el panel Catálogo, cargue la clase de entidad query_extents_36112 en el mapa actual pero detrás (debajo) de los datos bbox_36112<\/LI>En este ejemplo, las cajas de la cuadrícula de mosaicos de consulta están en verdeEstos mosaicos corresponden a un área en el mapa para la cual los bbox están solicitando datos<\/LI><\/UL><\/LI><\/UL><\/span><\/P>Acercarse al mapa puede proporcionar una mejor comprensión de la relación entre estos dos conjuntos de datos<\/LI>Como se ve en el mapa a continuación, algunos bbox están ligeramente desplazados entre sí pero aún comparten un mosaico común del grid debajo de ellos<\/LI>Las coordenadas de estos mosaicos de consulta (por ejemplo, desde la clase de entidad query_extent) son las que irán a los archivos CSV y finalmente a la prueba de carga JMeter<\/LI><\/UL><\/span><\/P>Mirar más cerca los bbox revela detalles sobre su composición respectiva de consultaPor ejemplo, algunos bbox podrían requerir 12 mosaicos "subyacentes" para cumplirse, otros 15 o 20<\/LI>Como se ve en el mapa a continuación, el bbox resaltado en negro requiere 12 mosaicos específicos coloreados en rojo<\/LI><\/UL><\/LI><\/UL><\/span><\/P> Nota: El diseño del grid de mosaicos del servicio de entidades es una de sus fortalezas clave ya que se presta a la repetibilidad. Esta repetibilidad puede aprovecharse con caching en un despliegue para mejorar la escalabilidad. Esto no es posible con export map.<\/STRONG><\/FONT><\/P>Examinar los archivos CSV generados revelará los resultados finales de esta transformación<\/LI>Ver el archivo query_extents_36112.csv en un editor de texto debería mostrar algo similar a lo siguienteDependiendo del lanzamiento de Load Test Tools, los archivos CSV podrían estar ordenados por la columna operationid<\/LI><\/UL><\/LI><\/UL><\/span><\/P>Dependiendo del lanzamiento de Load Testing Tools, la línea puede o no estar agrupada por la columna operationid<\/SPAN><\/LI>La comprensión del operationid, en este caso, es un concepto importante para las pruebas ya que cada operación representa una acción de navegación (por ejemplo, un paneo o zoom)
        

      • Desde el punto de vista de JMeter, una operación es lo mismo que una transacción
        
      color="#FF0000">Nota: Los JSR223 Samplers que usan Groovy generalmente se ejecutan rápidamente y añaden muy poca sobrecarga a la prueba

      

      Bucle de Operación y Población de Parámetros

      Con un id de operación elegido, el enfoque se convierte en la lógica del bucle donde la prueba buscará el número de consultas de servicios de características que componen la transacción. A partir de ahí, usará un tercer conjunto de JSR223 Samplers para poblar los parámetros de las solicitudes asociados al id de operación seleccionado previamente con cada iteración en el bucle. 

      • Hay un JSR223 Sampler para cada escala de mapa que llena las variables asociadas de JMeter basándose en el id de operación y el valor de iteración
        • Estos elementos luego se convierten en pares clave/valor que son recogidos por la Solicitud HTTP
        • Los valores de iteración son rastreados por un Elemento Configurador Contador
        • Estos JSR223 Samplers no necesitan ser editados para ejecutar la prueba
      • Cada Controlador de Bucle, Contador, JSR223 Sampler y objetos de Solicitud HTTP están todos colocados dentro de un Controlador de Transacción correspondiente para separar lógicamente los elementos para cada escala de mapa

      

      Solicitud HTTP

      Esencialmente, toda la lógica de prueba anterior existe solo para este componente de la prueba. Aquí, el objeto Solicitud HTTP de JMeter puede leer las variables de JMeter para parámetros específicos clave/valor que han sido poblados por el JSR223 Sampler inmediatamente antes.

      Dado que este enfoque es altamente programático, ¡solo hay una Solicitud HTTP por escala de mapa! Tal diseño favorece la mantenibilidad.

      

      Nota: Este enfoque de prueba también funcionaría para servicios tradicionales de capas de características no alojadas. Sin embargo, estos servicios no tienen las mismas optimizaciones en los parámetros de solicitud que los servicios alojados como maxAllowableOffset y quantizationParameters. Estas opciones simplemente tendrían que eliminarse de la Solicitud HTTP.

      Configuración del Grupo de Hilos

      El Plan de Prueba JMeter está configurado actualmente para una prueba relativamente corta de 10 minutos. En términos generales, los servicios alojados funcionan bien, por lo que habrá mucho rendimiento dentro de cada paso (1 minuto por paso) así como en toda la prueba.

      • Diferentes entornos y datos pueden requerir una configuración alternativa para lograr los resultados deseados, ajuste según sea necesario

      

      Validando el Plan de Prueba

      Como buena práctica, siempre es buena idea validar los resultados antes de ejecutar la prueba real de carga.

      • Use el listener View Results Tree para ayudar con la validación
        • El Plan de Prueba incluye un Listener View Results Tree pero está deshabilitado por defecto
          • Habilítelo para ver los resultados
      • Desde la GUI, inicie la prueba

      Transacciones 

      • Seleccione una de las Transacciones "HFS"
        • Los resultados deberían parecerse a lo siguiente:

      

      • En este ejemplo, las transacciones listadas arriba: HFS (mapscale: 72224), HFS (mapscale: 36112), y HFS (mapscale: 144448) todas completaron exitosamente
        • El resultado del Sampler lista algunos detalles más
          • Aunque cada Transacción envió una solicitud HTTP por extensión de consulta característica, la prueba JMeter cuenta el Sampler como parte de la operación
            • Los JSR223 Samplers añaden muy poca sobrecarga a la Transacción aunque duplican el número de muestras, esto es solo un detalle a tener en cuenta
      • Eche un vistazo rápido al Tamaño en bytes
        • En este ejemplo, el Tamaño de la Transacción fue casi 65KB lo que sugiere que se estaba devolviendo algún dato y las respuestas no estaban "vacías"

      Solicitudes

      • Expanda una de las Transacciones "HFS"
      • Seleccione una de las solicitudes https
        • Los resultados deberían parecerse a lo siguiente:

      

      • En este ejemplo, la solicitud select completó exitosamente
      • Eche un vistazo rápido al Tamaño en bytes
        • En este ejemplo, el Tamaño de la Solicitud fue aproximadamente 5KB lo que sugiere que se estaba devolviendo algún dato y las respuestas no estaban "vacías" (por ejemplo, 1500 bytes)
      • El ContentType también es importante
        • Según los parámetros en el Plan de Prueba, el formato solicitado es pbf que devuelve application/x-protobuf 
          • Solicitar protocol buffers es una buena práctica ya que optimiza la carga útil
            • El formato resultante es binario y no puede verse fácilmente sin ayuda adicional que no se cubre en este Artículo

      Nota: Los servicios feature (incluidos los servicios feature alojados) se renderizan en el cliente (no en el servidor como export map). Aunque Apache JMeter es un cliente (de prueba), no renderiza las respuestas del servidor mediante JavaScript como un navegador web.

      Ejecución de la Prueba

      La prueba de carga debe ejecutarse del mismo modo que un Plan típico de Prueba JMeter.

      Consulte el script runMe.bat incluido con el proyecto roads_hfs1.zip  para un ejemplo sobre cómo ejecutar una prueba según lo recomendado por el equipo Apache JMeter. 

      • El script runMe.bat contiene una variable jmeterbin que deberá configurarse con el valor apropiado para su entorno

      Nota: Siempre se recomienda coordinar la hora y duración del inicio de la prueba con el personal adecuado. Esto asegura un impacto mínimo a usuarios y otros colegas que también puedan necesitar usar el Sitio ArcGIS Enterprise. Además, esto ayuda a prevenir sistema noise de otras actividades y usos que puedan "contaminar" los resultados.

      Informe JMeter

      Curvas de Rendimiento (Throughput)

      • El Informe generado automáticamente por JMeter puede proporcionar información sobre el rendimiento (throughput) de las transacciones HFS bajo carga
      • Las transacciones no HFS han sido filtradas manualmente
      • En este caso, el pico máximo del rendimiento para las operaciones HFS fue aproximadamente 16.5 transacciones/segundo
        • Dado que hubo 3 transacciones HFS, esto equivale a casi 50 transacciones/segundo (o 178,200 transacciones/hora)

      

      Nota: Cada una de las Transacciones HFS naturalmente tendrá un rendimiento similar ya que su respectiva ejecución en la prueba tuvo igual peso.

      Curvas de Rendimiento (Performance)

      • El Informe generado automáticamente por JMeter puede proporcionar información sobre el rendimiento (performance) de las transacciones HFS bajo carga
        • Las transacciones no HFS han sido filtradas manualmente
      en este caso, las transacciones HFS para todas las escalas fueron sub-segundo (menos de 1 segundo)
      • Incluso hacia el final de la prueba, bajo la carga más pesada, el tiempo promedio de respuesta fue inferior a 225 ms o 0.225 segundos

    

    Reflexiones Finales

    Existen otras formas de probar consultas a un servicio de capa de entidades alojado, como a través del tráfico capturado desde un navegador web mientras se interactúa con el endpoint o la aplicación. Esto produciría una lista de las URLs del servicio que podrían traducirse en una prueba. Sin embargo, un enfoque programático como el listado en este Artículo ofrece una estrategia para probar un área espacial amplia del servicio cubriendo muchas más extensiones de las que se pueden hacer prácticamente con el enfoque de tráfico capturado.

    El enfoque programático también es más fácil de mantener ya que el tamaño del Plan de Prueba es mucho menor. Para poner esto en perspectiva, la prueba JMeter contenida en este Artículo solo contenía 3 Solicitudes HTTP (una para cada escala del mapa). 

    • Para descargar el Plan de Prueba Apache JMeter usado en este Artículo vea: roads_hfs1.zip
    • Para descargar el subconjunto de datos Natural Earth usado en este Artículo vea: Motor Vehicle Use Map: Roads (Feature Layer) 

     

     

     

    Apache JMeter lanzado bajo la Apache Licencia 2.0. Apache, Apache JMeter, JMeter, la pluma Apache y el logo Apache JMeter son marcas registradas de la Apache Software Foundation.

AaronLopez

Hi @StevenBeothy 

I think that test plan is valid and a good programmatic way to get a performance profile from each of the layers

However, there are a few items worth mentioning:

• My roads_hfs test requested * for the outFields
  • This is fine but can be considered aggressive, especially if the tables are "wide" (e.g., 50 or more attributes)
  • In that case, I would consider maybe asking for a few specific attributes (e.g., OBJECTID plus one or two others)
  • But, that assumes the requested attributes exist in all the layers
    • This is why using * is so easy
• My roads_hfs test was build around using hosted feature service queries (e.g., where resultType=tile)
  • I am a huge fan of the feature tiles and their data structure lends itself to efficient querying (repeatable extents for better caching, more predictable quantization tolerances for each of the layers)
  • A resultType of say standard would be similar but the test logic would be different (and in my opinion, more complex)
    
    • Additionally, requests with resultType=standard can ask for varying numbers of records being returned (through the use of the resultRecordCount and resultOffset parameters)
      • This adds variance and test complexity...which again is why I like testing with resultType=tile

To reiterate, I think your approach is good and resultType=tile style tests are a great way to consume a feature service.
I bring up these other items to give my opinion and perspective on what your test is doing and how its asking for the data...as well as the potential test logic impacts when asking for feature data when the resultType is not tile.

Hope that helps.