Benchmark ArcGIS Enterprise...El Enfoque Original
Hace un tiempo, hablé sobre el uso del conjunto de datos Natural Earth con una prueba preconfigurada de Apache JMeter para evaluar el rendimiento de una implementación de ArcGIS Enterprise. Los resultados de esa prueba podrían luego compararse con ejecuciones de otras implementaciones para obtener una idea comparativa del rendimiento y las características de escalabilidad del hardware subyacente. Este enfoque tenía algunos beneficios:
- Natural Earth es un conjunto de datos GIS gratuito
- Disponible para uso público
- Complejidad de datos baja a moderada (fácil de manejar)
- El Plan de Prueba presentaba una carga escalonada para observar las capacidades de escalabilidad
Aunque útil y un buen punto de referencia, el componente de escalabilidad significaba que la prueba normalmente se ejecutaría durante mucho tiempo (lo que también añadía cierta complicación). Me preguntaba si había una manera más fácil de simplemente evaluar el hardware de procesamiento (por ejemplo, la CPU) pero aún a través de ArcGIS Enterprise:
- ¿Era posible usar JMeter desde una perspectiva sólo de rendimiento?
- ¿Podría crear una prueba para evaluar ArcGIS Enterprise sin un conjunto de datos FGDB o geodatabase empresarial subyacente (lo que debería simplificar el esfuerzo general)?
Resulta que las respuestas fueron sí!
Benchmark ArcGIS Enterprise...Un Enfoque Alternativo
Bien... Estoy hablando con medias verdades. La nueva prueba benchmark no depende de un servicio basado en un conjunto de datos FGDB o eGDB, pero sí necesita algunos datos. Para ayudar a mantener las cosas simples, los datos (por ejemplo, geometrías pre-generadas) simplemente se pasan a través de los elementos de muestra JMeter a un recurso ArcGIS que no tiene un conjunto de datos referenciado detrás de escena.
Entonces, ¿cómo se hace esto?
A través del probado y verdadero servicio Geometry. El servicio geometry de ArcGIS Server es un recurso incorporado que proporciona acceso a muchas funciones para realizar operaciones geométricas. Los cálculos de estas operaciones (como buffer o generalize) pueden ser simples o complejos (dependiendo de lo que se le solicite). Desde la perspectiva de un analista de rendimiento, proporciona un medio fantástico para evaluar el hardware CPU de la máquina que ejecuta ArcGIS Server.
Nota: Aunque el término ArcGIS Enterprise incluye ArcGIS Server, este benchmark ejerce principalmente este último (por ejemplo, ArcGIS Server). Algo del tráfico puede pasar por el ArcGIS Web Adaptor y habrá una pequeña cantidad de autenticación Portal for ArcGIS, pero por diseño, la mayor parte del trabajo será realizado por ArcGIS Server.
Beneficios del Uso del servicio Geometry
El servicio Geometry ha estado presente en ArcGIS Server desde la versión 9.3, por lo que es ubicuo. Eso hace que una prueba que lo utilice sea fácil y confiable. Dado que los datos que impulsan la prueba se colocan dentro de los pares clave/valor de las solicitudes, eso añade portabilidad (por ejemplo, no hay conjunto de datos que transportar).
Nota: Aunque el servicio Geometry ha estado incluido con ArcGIS Server durante algún tiempo, por defecto está desactivado y no en ejecución. El servicio necesitaría ser iniciado y compartido con los miembros apropiados del Portal for ArcGIS antes de ejecutar la prueba.
Plan de Prueba Geometry_Functions_Benchmark
- Descargar y abrir el Plan de Prueba en Apache JMeter debería verse similar a lo siguiente:
- Ajuste las Variables Definidas por el Usuario para adaptarlas a su entorno

¿Qué Tipos de Funciones Deberían Ser Probadas?
Para un benchmark, la respuesta corta es sólo unas pocas. Este Plan de Prueba en particular sólo llama a unas pocas operaciones diferentes... así como las mismas operaciones en diferentes formas (por ejemplo, cambiando parámetros en la solicitud para obtener intencionalmente una respuesta variante). Esto proporciona mutabilidad para que la prueba no haga sólo lo mismo repetidamente.
A continuación se muestra un vistazo a las operaciones usadas en este benchmark:

Rendimiento Esperado del Test y Operaciones
Esta prueba tiene algunas operaciones que pueden ejecutarse rápido y otras que tomarán más tiempo. Esta velocidad variará según el hardware. En última instancia, sólo queremos que ArcGIS Enterprise (por ejemplo, Server) funcione durante unos pocos minutos para poder obtener una idea del rendimiento del procesamiento. Si cada operación tomara 10 minutos (con la prueba muchas veces más larga) el benchmark mismo podría volverse demasiado largo y menos práctico para usar.
Ejemplo Arquitectura Despliegue
Esta prueba benchmark se ejecutó en un laboratorio contra dos servidores diferentes (por ejemplo, ejecutada una vez por servidor):
- ArcGIS Enterprise -- Máquina #1 (hardware más antiguo)
- Intel Xeon E5-4650, 2.70 GHz
- SPECint_base2006
- Puntuación: 50.5
- 32 núcleos de procesamiento
- HyperThreading deshabilitado
- 64GB RAM
- Red 10Gbps
- ArcGIS Enterprise -- Máquina #2 (hardware más nuevo)
- Intel Xeon Gold 6126, 2.60 GHz
- SPECint_base2006
- Puntuación: 71.9
- 24 núcleos de procesamiento
- HyperThreading deshabilitado
- 128GB RAM
- Red 10Gbps
Nota: Dado que este esfuerzo de prueba se centró más en la velocidad en lugar del rendimiento total, se usaron números SPECint_base en lugar de SPECint_rate_base.
Ejecución del Test Benchmark
Para pruebas largas, no se recomienda ejecutar el Plan de Prueba dentro del GUI. Sin embargo, dado que esta es una prueba relativamente corta, el impacto es nominal.
Nota: Al ejecutar cualquier prueba, siempre se recomienda coordinar la hora de inicio y duración esperada con el personal apropiado. Esto asegura un impacto mínimo a los usuarios y otros colegas que también puedan necesitar usar el Sitio ArcGIS Enterprise en cuestión (por ejemplo, la implementación en producción). Además, esto ayuda a prevenir ruido del sistema de otras actividades y usos que puedan "contaminar" los resultados del test.
Resultados
Después de ajustar las Variables Definidas por el Usuario para apuntar al entorno apropiado (Máquina #1…devlab05), el benchmark se ejecutó directamente en la GUI JMeter. Los resultados pueden observarse desde el elemento Ver Resultados en Tabla:
- Para conveniencia, el Plan de Prueba calcula automáticamente la duración total del test, justo en el nombre de la última operación
- Esto facilita observar el tiempo benchmark desde la tabla

< LI >El Plan De Prueba fue ajustado para apuntar a un servidor con hardware más nuevo (Máquina #2…eistsrv05) y se volvió a ejecutar el benchmark < UL >< LI >Desde la tabla , los resultados se agregan después De La primera ejecución : </ LI ></ UL ></ LI ></ UL >< P ><\/span><\/SPAN><\/P>Como era de esperar, la primera máquina requirió más tiempo para completar las mismas operaciones. Esto resultó en una diferencia medible en el rendimiento entre las dos máquinas.<\/SPAN><\/P>- Máquina #1…devlab05
- Duración del benchmark: 259946 ms<\/LI><\/UL><\/LI>
- Máquina #2…eistsrv05
- Duración del benchmark: 181441 ms<\/LI><\/UL><\/LI><\/UL>
Calcular el Cambio Porcentual<\/H2>Dado que los tiempos de respuesta fueron menores (por ejemplo, más rápidos) con hardware más nuevo (en comparación con la primera ejecución en hardware más antiguo), calcularemos una disminución porcentual<\/EM>:<\/P>Primero, tiempo original del servidor - tiempo del servidor nuevo = la disminución<\/LI>Luego, la disminución ÷ número original del servidor × 100 = el % de disminución<\/LI><\/UL>(259946 ms - 181441 ms) / 259946 ms = 0.302<\/P>0.302 x 100 = 30.2% <\/P>Los tiempos del benchmark del hardware más antiguo (nuestro punto de partida) fueron un 30% más altos que el hardware más nuevo<\/U>. Este cambio porcentual sugiere una mejora medible al usar el hardware más nuevo.<\/P>Estimación del Cambio Porcentual Basada en SPEC<\/H2>Usemos la relación SPEC con el tiempo del benchmark de la ejecución original para predecir el target_time (tiempo del benchmark en la máquina nueva). Esto puede ayudar a entender si se podría estimar aproximadamente el mismo cambio porcentual.<\/P>(Baseline_SPEC x Baseline_Time) = (Target_SPEC x Target_Time)<\/P>((Baseline_SPEC x Baseline_Time) / Target_SPEC) = Target_Time<\/P>(36.875 x 259946 ms) / 53.75 = 178335 ms (después de redondear hacia abajo al segundo más cercano)<\/P>(259946 ms - 178335 ms) / 259946 ms = 0.314<\/P>0.314 x 100 = 31.4%<\/P>Según esta predicción, se estimó que el hardware antiguo era un 31% más lento que con el hardware nuevo. Esto está muy cerca del cambio porcentual que se calculó basado en los tiempos observados del benchmark.<\/U> <\/P>Hardware Futuro<\/H1>
<\/span>Las arquitecturas de procesadores y las velocidades de CPU siempre están mejorando. Eventualmente<\/EM>, tal prueba de benchmark (tal como está construida actualmente) podría tomar solo un minuto o decenas de segundos para ejecutarse (qué gran problema tener). En ese punto, se podría agregar complejidad a la prueba para aumentar su duración y así coincidir mejor con la nueva tecnología.<\/P>Puede que haya notado que la última transacción en la prueba fue deshabilitada. Esta solicitud de Buffer de 1000 Puntos con una distancia de 10000 metros y una unidad de 9035 (Distancia Internacional en Metros) toma algo de tiempo para calcularse (incluso en hardware decente). Fue deshabilitada para acortar el tiempo de ejecución a una duración razonable. Sin embargo, si es útil, puede habilitarse como un cálculo adicional, dependiendo de la velocidad de CPU del despliegue de interés.<\/P>Reflexiones Finales <\/H1>Como se mencionó en otros artículos comunitarios, no existe un único servicio o función que pueda cubrir toda la amplitud y profundidad de ArcGIS. Sin embargo, el servicio Geometry es un recurso que representa una porción del increíble campo de GIS que es fácil de trabajar. Esto lo convierte en una buena opción para usar en esfuerzos de pruebas benchmark.<\/P>¿Un Tiempo de Respuesta Rápido Se Trata Solo De La Velocidad De La CPU, Correcto?<\/H2>Para esta prueba benchmark Geometry, sí. Sin embargo, para servicios del mundo real, la velocidad de procesamiento no es el único factor.<\/P>Componentes del hardware del servidor como la velocidad del disco, memoria disponible y velocidad de red son otros recursos que pueden mejorar los tiempos de respuesta (además de la velocidad de CPU). Juntos, todos tienen un efecto positivo en la experiencia del usuario.<\/P>Este benchmark se centró en el rendimiento de la CPU ya que es una gran parte del proceso solicitud cliente/respuesta servidor, pero como se mencionó, no es el único recurso del servidor cuando se consideran otros posibles servicios ArcGIS.<\/P>¿Qué Hay De Otras Herramientas De Comparación De CPU?<\/H2>
<\/span>Existen muchas utilidades que pueden perfilar y probar las diversas piezas del hardware del servidor usando toda una batería de ejercicios. Estas pruebas son excelentes y ciertamente agregan valor para entender el hardware. Nuevamente, no hay una prueba única que pueda representar todas las cosas GIS. Pero esperamos que este Plan De Prueba Benchmark Geometry pueda ser una herramienta útil en el arsenal del analista. <\/P>
<\/P>Para descargar el Plan De Prueba Apache JMeter usado en este Artículo vea: geometry_functions_benchmark1.zip<\/A><\/STRONG> <\/P> <\/P>
<\/P>
<\/P>
Atribución<\/STRONG><\/P>Recurso:
Archivo:Wikimedia_Foundation_Servers-8055_43.jpg<\/A><\/P>Descripción: Servidores PowerEdge montados en rack de undécima generación<\/SPAN><\/P>Autor:
Victorgrigas<\/A> - Trabajo propio<\/SPAN><\/P>Creado: 16 julio 2012<\/SPAN><\/P>Subido: 20 julio 2012<\/SPAN><\/P>Licencia: CC BY-SA 3.0<\/A>, Enlace<\/A> <\/P> <\/P>
Recurso:
Archivo:Cpu-processor.jpg<\/A><\/P>Descripción:<\/P>
Autor:
Fx Mehdi<\/A> - Trabajo propio<\/SPAN><\/P>Cargado: <\/SPAN>30 mayo 2019<\/SPAN>
Licencia: Creative Commons Attribution-Share Alike 4.0 International