nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Capturando la Utilización de Hardware Durante una Prueba de Carga Apache JMeter (Intermedio)

AaronLopez

Capturando la Utilización de Hardware Durante una Prueba de Carga Apache JMeter

El rendimiento medido de transacciones y los tiempos de respuesta son datos críticos de cualquier prueba de carga de ArcGIS Enterprise, pero la utilización de hardware capturada de las máquinas del despliegue también proporciona información vital. Juntos, estos artefactos de prueba permiten el análisis adecuado de las capacidades y eficiencias del Sitio.

Determinar que una aplicación o servicio de características ha alcanzado un nivel particular de rendimiento es bueno, pero confirmar las características de escalabilidad mientras se examina la utilización del procesador capturada de la carga de trabajo probada es aún mejor.

Este Artículo discutirá varias formas de capturar la utilización del hardware de la máquina. Este uso de recursos es un gran complemento a los resultados de una prueba de carga Apache JMeter de ArcGIS Enterprise y puede ayudar a profundizar el análisis. El Artículo se centrará en los escenarios más comunes utilizando herramientas y utilidades gratuitas para Windows y Linux.

Estrategias de Captura

Desafortunadamente, no existe una solución única para capturar la utilización del hardware en una prueba de carga. Dada la posibilidad de una multitud de diferentes entornos (Windows, Linux, Cloud, Kubernetes, Docker, etc...) o la falta de acceso y permisos requeridos, puede haber casos donde necesite alterar su estrategia y metodología para capturar y monitorear la información de uso de su hardware mientras se ejecutan las pruebas Apache JMeter.

Por ejemplo, perfmon (por ejemplo, Performance Monitor) es gratuito e incluido con cada instancia de Microsoft Windows y puede funcionar muy bien cuando todas las máquinas en el entorno están en Windows. Es el frontend para varias tecnologías Windows (por ejemplo, WMI, DCOM) y todas juntas ofrecen un marco versátil para monitorear la utilización del hardware en "tiempo real" con gráficos o mediante scripting para capturar recursos en un archivo de datos.

Sin embargo, perfmon no está disponible para Linux por lo que se necesitaría otra herramienta (por ejemplo, dstat) para capturar la información equivalente. Por supuesto, incluso con una configuración totalmente Windows, pueden surgir desafíos con el enfoque perfmon, como en entornos cloud restrictivos. Pero, ¿existen otras formas de registrar estos valiosos datos de la máquina? Exploraremos la respuesta a esa pregunta más adelante en este Artículo.

¿Qué Información Debe Capturar la Prueba de Carga?

Cuando trabajos GIS como generar una imagen de mapa o calcular una solicitud del servicio Geoprocessing se envían a un despliegue ArcGIS Enterprise, las máquinas servidoras que trabajan en la respuesta utilizarán varios recursos hardware para completar el trabajo. Idealmente, la mayor parte del trabajo ocurre en la unidad central de procesamiento (CPU) pero esto no siempre es así.

Independientemente de la tecnología usada para monitorear y capturar el uso para su prueba de carga, existen cuatro categorías principales de contadores hardware que todas las máquinas servidoras tienen:

Procesador
Memoria
Red
Disco

Cada categoría tiene una variedad de métricas que pueden usarse para mostrar la utilización de ese recurso. No es necesario (ni recomendado) capturar cada métrica disponible del procesador durante una prueba... solo las vitales. En otras palabras, las necesarias para responder preguntas típicas sobre pruebas de carga o la historia particular que busca.

Típicamente, algunas métricas importantes incluyen las siguientes:

Procesador
- Porcentaje de utilización
Memoria
- Disponible (MB o bytes)
- Usada (MB o bytes)
- Porcentaje usado
Red
- Enviado (MB o bytes)
- Recibido (MB o bytes)
Disco
- Porcentaje inactivo
- Longitud de cola
- Lectura (MB o bytes)
- Escritura (MB o bytes)

Nota: Si sus servidores tienen múltiples discos, se recomienda encarecidamente recopilar datos en todos ellos pero por separado. En otras palabras, trate la unidad C, unidad D y unidad E como recursos diferentes al capturar su uso. Técnicamente es posible tener múltiples dispositivos Network activos pero no es muy común.

La interfaz Performance Monitor recopilando diversas métricas hardware que han sido añadidas manualmente (a perfmon):

Nota: Algunas metodologías para capturar la utilización guardarán los valores en bytes mientras que otras usan megabytes. Cualquiera está bien, pero es importante entender cuál se está capturando para el análisis y presentación del informe.

Nota: Junto con el rendimiento transaccional (por ejemplo transacciones/seg) y los tiempos de respuesta transaccionales (por ejemplo segundos), las métricas listadas arriba constituyen la mayor parte de los Indicadores Clave de Rendimiento (KPIs) en una prueba carga. Los KPIs ayudan a evaluar y comparar el éxito de una prueba o esfuerzo particular contra objetivos definidos (por ejemplo el Plan de Prueba).

Intervalo Muestral

Típicamente, una prueba carga (con enfoque principal en escalabilidad) no dura más que una o dos horas. Dado que eso se considera una duración relativamente corta, tiene sentido capturar la utilización del hardware con un intervalo rápido (por ejemplo frecuencia corta) entre 5 a 10 segundos. Esto ayuda a asegurar que se obtenga suficiente dato para realizar un análisis exhaustivo. Si el intervalo captura es 1 minuto o más largo, algunos impactos significativos a los recursos hardware (de la prueba) podrían perderse.

Nota: Puede que ya haya software monitorizando su red periódicamente recopilando utilización hardware desde sus servidores ArcGIS Enterprise. Si hay informes generados disponibles pueden usarse para análisis pruebas carga siempre que el intervalo captura sea corto (por ejemplo 5 a 10 segundos). Para análisis pruebas carga interesa buen detalle métrico por unas pocas horas más que cobertura métrica amplia por todo un día.

La Diferencia Entre Capturar y Monitorear

Los términos "capturar" y "monitorear" utilización hardware a menudo se usan indistintamente. Sin embargo, para propósitos pruebas Apache JMeter este Artículo se enfoca en capturar el uso más que monitorearlo. La diferencia clave aquí es que capturar significa que estamos registrando o guardando la información para facilitar el análisis posterior a la prueba.

Clientes Prueba (Máquinas Generadoras Carga)

Al capturar utilización hardware desde una prueba carga contra ArcGIS Enterprise es buena práctica medir también el uso desde las máquinas Cliente Prueba.
Comprensiblemente, la mayor parte del enfoque está puesto en observar los recursos servidor pero el hardware desde los clientes prueba también puede ser un cuello botella. Si estas máquinas no tienen suficiente capacidad (por ejemplo procesador, memoria, red o disco) ¡la capacidad para generar carga contra su despliegue será impactada negativamente!

Entienda sus Líneas Base Servidor

Si no está muy familiarizado con el hardware del despliegue ArcGIS Enterprise se recomienda observar la utilización recursos mientras el sistema está inactivo. Este "uso" ayudará a formar una imagen mental del mejor escenario posible. En otras palabras, cómo luce la máquina cuando el software y servicios están corriendo pero nadie lo usa. En tal escenario, actividad recurso desde las cuatro categorías hardware dbería ser mínima.
Una prueba carga no necesita registrar esta información del "estado inactivo" pero es bueno estar consciente cómo luce.

Nota: Usar herramientas como Task Manager (para Windows) o top (para Linux) son excelentes herramientas para obtener manualmente una vista rápida del uso recursos sistema. Sin embargo, no son ideales para guardar uso desde todas las categorías a un archivo.

Vista Task Manager del uso recursos sistema (Windows):

Vista top del uso recursos sistema (Linux):

Ejemplos Comunes Captura Utilización

Usando Perfmon (Para Capturar Utilización Fuera De La Prueba De Carga)

Dado que los permisos requeridos están disponibles para su cuenta usuario en Windows, perfmon es uno de las formas más fáciles de registrar la utilización del hardware para el análisis de pruebas de carga. Performance Monitor (y las tecnologías de soporte) pueden capturar el uso desde la máquina local o múltiples servidores remotos, simultáneamente.<\/P>

Nota: Como recordatorio, las métricas disponibles para perfmon dentro de cada grupo de hardware son abundantes.<\/STRONG><\/FONT>
También hay una gran cantidad de métricas de software que se pueden capturar. Pero en este caso, menos es más. Solo se necesita un pequeño número de contadores para la mayoría de las situaciones.<\/STRONG><\/FONT><\/P>Como se mencionó anteriormente, donde puede haber consideraciones:<\/P>La implementación de ArcGIS Enterprise se está ejecutando en Linuxperfmon no está disponible para LinuxLa solución más fácil es usar otra metodología para recopilar la información (discutida más adelante)<\/LI><\/UL><\/LI><\/UL><\/LI>La implementación está en la nubeEjecutar erfmon en la nube para recopilar desde otras máquinas de implementación (en la nube) es técnicamente posible pero detrás de escena utiliza protocolos de red que normalmente están bloqueados en el entornoLa solución más fácil aquí es ejecutar perfmon manualmente en cada máquina en la nube y recopilar las salidas generadas cuando la prueba haya finalizado<\/LI><\/UL><\/LI><\/UL><\/LI><\/UL>Iniciar perfmon en Windows es tan simple como ejecutar:<\/P>Ejecutar --> perfmon<\/LI><\/UL>Desde allí puedes agregar cada máquina así como cada métrica y contador de hardware respectivo. Aunque esto es muy poderoso, puede consumir mucho tiempo y ser propenso a errores tipográficos.<\/P>En cambio, la estrategia recomendada para esta metodología es usar un script de PowerShell donde todos estos elementos están predefinidos.<\/P>Lo siguiente recopilará métricas clave de perfmon (que ya están definidas) de las cuatro categorías principales de hardware y lo hará para cuatro máquinas diferentes (que puedes especificar):<\/LI><\/UL> <\/P># =============================================================================== # Actualizado: 2022-08-02 # NombreArchivo: ps_get_all_continuous.ps1 # Versión: 0.1.0 # Descripción: Recopilar continuamente varias métricas y guardar valores (binarios) en un archivo # Notas: Se recomienda iniciar la recopilación de métricas 20 segundos antes de que comience la prueba # ya que la inicialización del contador puede tomar algún tiempo # =============================================================================== Write-Output -InputObject 'Recopilando todas las métricas (continuo)...' # Variables # Contador(es) Windows Perfmon $counters = "Processor(_Total)\% Processor Time","Memory\Available MBytes","Memory\Committed Bytes","Memory\% Committed Bytes In Use","Network Interface(*)\Bytes Received/sec","Network Interface(*)\Bytes Sent/sec","LogicalDisk(_Total)\% Idle Time","LogicalDisk(_Total)\Disk Read Bytes/sec","LogicalDisk(_Total)\Disk Write Bytes/sec" # Máquinas desde las cuales recopilar $computers = @('server1.domain.com','server2.domain.com','server3.domain.com','server4.domain.com') # Tiempo en segundos entre cada recopilación de muestra $sampleinterval = 10 $date = (Get-Date) $dyndate = '{0:yyyyMMddTHHmmss}' -f $date # 20220303T140044 # Nombre del archivo $filename = "perfmon_all_continuous" # Tipo de archivo de salida (las opciones son blg, csv o tsv) $outputfiletype = "blg" # Archivo de salida $outputfile = '{0}_{1}.{2}' -f $filename, $dyndate, $outputfiletype # Get-counter Write-Output -InputObject ('Fecha y hora inicio: {0}' -f $date) Get-counter -Computername $computers -Counter $counters -Continuous -Sampleinterval $sampleinterval | Export-counter -Force -FileFormat $outputfiletype -Path $outputfile <\/code><\/pre> <\/P><UL><LI>Las métricas se recopilan cada 10 segundos hasta que presiones Ctrl-C en la ventana PowerShell<\/U>. La información se guarda en un archivo con formato binario que puedes abrir en Windows (para análisis o transformación adicional):<\/LI><\/UL><img src="https:\/\/us.v-cdn.net\/6038851\/uploads\/images\/49356iC6B4C3B9199D2CF8\/capturehardware_powershell_start_output.png" role="button" title="capturehardware_powershell_start_output.png" alt="capturehardware_powershell_start_output.png" \/><\/P>Nota: Se recomienda iniciar este script Powershell aproximadamente 20 o 30 segundos antes<\/U> de comenzar la prueba de carga ya que la inicialización del contador no es inmediata y toma uno o dos momentos.<\/FONT><\/STRONG><\/P><UL><LI>Puedes abrir el archivo *.blg en cualquier momento durante la captura, pero la información más reciente no se vacía ni guarda en el archivo hasta que presiones Ctrl-C desde la ventana PowerShell donde se ejecuta el script.<\/LI><LI>Doble clic para abrir el archivo *.blg debería verse similar a lo siguiente:<\/LI><\/UL><img src="https:\/\/us.v-cdn.net\/6038851\/uploads\/images\/49377i9D7D47D522AD17A4\/capturehardware_powershell_results.png" role="button" title="capturehardware_powershell_results.png" alt="capturehardware_powershell_results.png" \/><\/P>El resultado final es una salida que se parece mucho a lo que capturamos. Sin embargo, en este caso, el proceso ha sido automatizado (lo cual es bueno).<\/SPAN><\/P>Desde esta interfaz en Performance Monitor, puedes seleccionar/deseleccionar métricas para aislamiento específico, exportar el gráfico como imagen, guardar los datos sin procesar a otro formato como CSV o realizar análisis de uso desde todas las máquinas recopiladas. ¡Muy poderoso!<\/SPAN><\/P>Nota: Los scripts Performance Monitor no se integran directamente con JMeter. <\/STRONG><\/FONT><\/SPAN><\/P>Nota: Para implementaciones en la nube, puede que tengas que ejecutar el script perfmon manualmente en cada servidor respectivo.<\/STRONG><\/FONT><\/SPAN><\/P><H3 id="toc-hId--464400263">Uso de dstat (Para Capturar Utilización Fuera de Prueba de Carga)<\/H3>dstat es una herramienta gratuita de línea de comandos (escrita por dag@wieers.com) disponible para (o con) la mayoría de distribuciones Linux que captura (y monitorea) la utilización del hardware. Aunque la utilidad no ha sido actualizada por varios años, es bastante robusta y fácil de scriptar.<\/P><UL><LI>Salida terminal dstat ejecutándolo sin opciones:<\/LI><\/UL><img src="https:\/\/us.v-cdn.net\/6038851\/uploads\/images\/49381i3426B23A73682927\/capturehardware_dstat_monitor.png" role="button" title="capturehardware_dstat_monitor.png" alt="capturehardware_dstat_monitor.png" \/><\/P>Lo siguiente se ejecutará en tu servidor Linux y capturará el uso del hardware a un archivo csv cada 5 segundos hasta que lo detengas manualmente con Ctrl-C<\/U>:<\/P><UL><LI>[gisadmin@pesrv04 ~]$ dstat -tTcmn --disk-util -d --nocolor --noheaders --output dstat_20220823.csv 5<\/STRONG></LI></UL><img src="https:\/\/us.v-cdn.net\/6038851\/uploads\/images\/49383i12F99873FC093EA3\/capturehardware_dstat_capture.png" role="button" title="capturehardware_dstat_capture.png" alt="capturehardware_dstat_capture.png" \/><\/P>Nota: Con dstat, el uso del procesador capturado es "porcentaje de tiempo inactivo", no porcentaje de uso. Para obtener el porcentaje de uso, resta 100 al valor. Sin embargo, la utilización del disco está en porcentaje de uso. Además, la salida anterior incluye un formato de presentación por lo que los valores sin procesar (no mostrados) para memoria, red y disco se guardan como bytes.<\/STRONG>Nota: Los scripts dstat tendrían que ejecutarse manual y separadamente en cada máquina Linux en la implementación. No se integran directamente con JMeter. Una vez terminada una prueba de carga y detenidos los scripts, los archivos CSV pueden ser recolectados y analizados (por ejemplo graficados o tabulados en un programa hoja de cálculo).< H3 id = "toc-hId-2023112570">Uso Apache JMeter (Para Capturar Utilización Directamente Desde Prueba De Carga)< / H3 >Aunque tiene algunos pasos más (así como sus propios obstáculos) que los scripts perfmon y dstat, usar Apache JMeter para capturar utilización del hardware tiene una ventaja principal:< UL >< LI >Consistencia. El mismo Plan De Pruebas JMeter puede usarse para capturar las mismas métricas hardware desde Windows y Linux (y Mac)< UL >< LI >Esto se logra mediante varios programas gratuitos:< UL >< LI >La < A href = "https://jmeter-plugins.org/wiki/PerfMon/" target = "_blank" rel = "noopener nofollow noreferrer">jp@gc - PerfMon Metrics Collector</ A > extensión que se añade a JMeter  < UL >< LI >Este componente se usa para definir qué métricas recopilar y desde qué máquinas< / LI >< / UL >< / LI >< LI >La < A href = "https://github.com/undera/perfmon-agent/blob/master/README.md" target = "_blank" rel = "noopener nofollow noreferrer">PerfMon Server Agent</ A > herramienta que corre en un Entorno De Ejecución Java (JRE) en cada servidor en la implementación < UL >< LI >Este componente realiza la recopilación real en cada servidor y envía los datos al JMeter< / LI >< / UL >< / LI >< / UL >< / LI >< / UL >< / LI >< / UL >El componente jp@gc - PerfMon Metrics Collector puede añadirse fácilmente al Plan De Pruebas a través del Gestor De Plugins JMeter (encontrado bajo "PerfMon (Servers Performance Monitoring):< img src = "https://us.v-cdn.net/6038851/uploads/images/49709i9536381D99067E93/capturehardware_jmeter_pluginmanager.png" role = "button" title = "capturehardware_jmeter_pluginmanager.png" alt = "capturehardware_jmeter_pluginmanager.png" />El El componente PerfMon Server Agent es relativamente fácil de agregar pero requiere algunos pasos adicionales para que funcione correctamente.<\/SPAN><\/P>Nota: Debido a un error en la biblioteca sigar-amd64-winnt, el ServerAgent se bloquea<\/EM> si usas la biblioteca predeterminada con JDK o JRE mayor a la versión 8. La solución es parchear la biblioteca o usar una versión actualizada de JRE 8.<\/STRONG><\/FONT><\/P><A href="https:\/\/www.openlogic.com\/openjdk-downloads" target="_self" rel="nofollow noopener noreferrer">OpenLogic<\/A> proporciona versiones gratuitas y actualizadas periódicamente de OpenJDK v8 (y JRE) para descargar en Windows, Linux y Mac. Aunque el JDK funcionaría, se recomienda el JRE en este caso ya que es un paquete más pequeño para descargar pero aún proporciona el entorno necesario para que el agente funcione. <\/FONT><\/P>Nota: Tanto el JRE de 32bit como el de 64bit funcionarán para ServerAgent.<\/STRONG><\/FONT><\/P>Nota: El OpenLogic JDK o JRE también puede usarse para ejecutar Apache JMeter directamente.<\/STRONG><\/FONT><\/P><img src="https:\/\/us.v-cdn.net\/6038851\/uploads\/images\/49406iEBD98A1C9C85F57D\/capturehardware_openlogic_download.png" role="button" title="capturehardware_openlogic_download.png" alt="capturehardware_openlogic_download.png" \/><\/span><\/FONT><\/P><UL><LI>El ServerAgent y OpenLogic JRE descomprimidos en la misma carpeta:<\/SPAN><\/FONT><\/LI><\/UL><img src="https:\/\/us.v-cdn.net\/6038851\/uploads\/images\/49499i1001834053E61544\/capturehardware_openlogic_serveragent_explorer.png" role="button" title="capturehardware_openlogic_serveragent_explorer.png" alt="capturehardware_openlogic_serveragent_explorer.png" \/><\/span><\/FONT><\/FONT><\/P><UL><LI> El OpenLogic JRE movido dentro de la carpeta ServerAgent:<\/LI><\/UL><img src="https:\/\/us.v-cdn.net\/6038851\/uploads\/images\/49500i9E7477A4EACB100A\/capturehardware_openlogic_serveragent_jre.png" role="button" title="capturehardware_openlogic_serveragent_jre.png" alt="capturehardware_openlogic_serveragent_jre.png" \/><\/span><\/FONT><\/FONT><\/P><UL><LI>Abre el archivo startAgent.bat en un editor y actualízalo con el nombre del directorio JRE que fue copiado dentro de la carpeta ServerAgent:<\/LI><\/UL> <\/P><pre class="lia-code-sample language-csharp"><code> off\n\nset JAVAPATH=.\\openlogic-openjdk-jre-8u342-b07-windows-64\\bin\n%JAVAPATH%\\java -jar %0\\..\\CMDRunner.jar --tool PerfMonAgent %*<\/code><\/pre> <\/P><UL><LI>Guarda los cambios<\/LI><LI>La carpeta C:\JMeterAgent\ServerAgent-2.2.3 ahora tiene un ServerAgent autónomo que puede copiarse a las máquinas apropiadas para recopilar su utilización de hardware<\/LI><LI>Para iniciar el agente en Windows<\/STRONG>, haz doble clic en startAgent.bat<UL><LI>El agente se abrirá en una ventana de comandos:<\/LI><\/UL><\/LI><\/UL><img src="https:\/\/us.v-cdn.net\/6038851\/uploads\/images\/49501iB7B6D67885E49A9C\/capturehardware_serveragent_listening.png" role="button" title="capturehardware_serveragent_listening.png" alt="capturehardware_serveragent_listening.png" \/><\/span><\/P><UL><LI>El agente no comenzará a "recopilar" métricas hasta que sea dirigido por el Plan de Pruebas Apache JMeter <UL><LI>Por defecto, el agente y JMeter se comunicarán entre sí por los puertos TCP y UDP 4444<\/LI><\/UL><\/LI><\/UL>Nota: El jp@gc - PerfMon Metrics Collector usa el nombre "perfmon" pero no<\/> utiliza realmente la tecnología Windows Performance Monitor.<\/STRONG><\/FONT><\/P><H1 id="toc-hId--737670810">El Plan de Pruebas SampleWorldCities <\/>con soporte para recopilación de métricas<\/><\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/> <\/><UL> Ubicación de la carpeta raíz del Plan de Pruebas JMeter (por ejemplo, la carpeta donde reside el Plan de Pruebas) set projectdir=%~dp0 rem Nombre del Plan de Pruebas JMeter (sin la extensión del archivo JMX) set testname=sampleworldcities5 rem Cadena añadida al archivo de resultados de cada ejecución de prueba set runname=testrun1 rem Configuración del Proxy rem set proxyhost=http:\/\/localhost rem set proxyport=8888 rem ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ rem *** Arranca tus motores *** color 20 rem Establecer variable de entorno para referenciar en la prueba (por ejemplo, ${__P(env.run)}) set jvm_args="-Denv.runname=%testname%_%runname%" echo on rem *** Prueba iniciada *** %javadir%\java.exe --illegal-access=warn %jvm_args% %heap% -jar %jmeterbin%\ApacheJMeter.jar -Jjmeter.save.saveservice.autoflush=false -n -f -t "%projectdir%\%testname%.jmx" ^ -l "%projectdir%\results\results_%testname%_%runname%.jtl" ^ -j "%projectdir%\logs\debug_%testname%_%runname%.log" ^ -e -o "%projectdir%\reports\%testname%_%runname%" ^ rem descomenta según sea necesario rem -H %proxyhost% -P %proxyport% ^ rem *** Prueba completada *** echo off color 40 ping localhost -n 5 color 07

Nota: Siempre es recomendado coordinar la hora de inicio y duración de la prueba de carga con el personal apropiado de su organización. Esto asegura un impacto mínimo a los usuarios y otros colegas que también puedan necesitar usar su Sitio ArcGIS Enterprise on-premise. Además, esto ayuda a prevenir ruido del sistema por otras actividades y usos que pueden "contaminar" los resultados de la prueba.

Nota: Por varias razones, se recomienda encarecidamente no realizar pruebas de carga en servicios proporcionados por ArcGIS Online.

Guía Metodológica General

Esta guía no pretende ser exhaustiva cubriendo todos los escenarios de captura de utilización de hardware.

Escenario #1
- Servidores
  - Windows
- Entorno
  - On-premise
- Máquina recolectora (Cliente de prueba)
  - Windows
- Descripción
  - Capturando uso de Windows desde Windows
- Dificultad
  - Fácil/Moderado
- Metodología recomendada
  - Windows Perfmon (a través de script PowerShell)

Escenario #2
- Servidores
  - Windows/Linux
- Entorno
  - On-premise
- Máquina recolectora (Cliente de prueba)
  - Windows
- Descripción
  - Capturando uso Windows/Linux desde Windows
- Dificultad
  - Moderado
- Metodología recomendada
  - JMeter Perfmon Extension and ServerAgent

Escenario #3
- Servidores
  - Linux
- Entorno
  - On-premise
- Máquina recolectora (Cliente de prueba)
  - Windows/Linux
- Descripción
  - Capturando uso Linux desde Windows/Linux
- Dificultad
  - Fácil/Moderado
- Metodología recomendada
  - dstat command or script

Escenario #4
- Servidores
  - Windows/Linux
- Entorno
  - Nube
- Máquina recolectora (Cliente de prueba)
  - Windows
- Descripción
  - Capturando uso Windows/Linux desde Windows
- Dificultad
  - Moderado
- Metodología recomendada
  - Cloud Watch/Azure Monitor (no cubierto en este Artículo)

Escenario #5
- Servidores
  - Windows
- Entorno
  - Nube
  Máquina recolectora (Cliente de prueba)Kubernetes;Desafíos Comunes en la Recolección de Utilización;
  ; Capturar la utilización del hardware de las máquinas del despliegue para una prueba de carga es una buena práctica pero no siempre es posible.;
  ;
  ; Los desafíos más típicos son: ;
  ;
  - ; Permisos ;
    - ; El más común ;
    - ; No haber recibido acceso o la capacidad para capturar uso desde servidores remotos es el desafío más común ;
    ;
  - ; Entorno/Ubicación ;
    - ; Capturar utilización desde máquinas en la red local es una cosa, capturar uso desde máquinas en la nube es otra cosa ;
    ;
  - ; Sistema Operativo ;
    - ; A veces el SO presenta sus propios *obstáculos* para capturar la utilización ;
    ;
  - ; Técnico ;
    - ; Ciertos entornos (por ejemplo Kubernetes/Docker) pueden no tener las mismas APIs para capturar el uso que una máquina tradicional (física o virtual) ;
    ;
  ;
  Reflexiones Finales
  ;
  ; En pocas palabras, hay muchas maneras para capturar información sobre la utilización del hardware desde las máquinas en un despliegue ArcGIS Enterprise para analizar con los resultados de su prueba de carga. La mejor manera para capturarla... cualquier forma que funcione mejor donde pueda registrar rápidamente la información y usarla para un análisis efectivo.;
  ;
  ; Aunque ningún Artículo puede cubrir todas las situaciones, entornos y escenarios, este lista varias metodologías para capturar estos datos para los comunes. ;
  ;
  ;

Encuentra más publicaciones etiquetadas con

Operational Support

Strategy & Planning

Architecture & Security

Comentarios

AaronLopez

Hi @ErickTGG,
Any observability tool could be used to capture operation data like CPU and memory usage from a performance/load test. And, if these reports and filters already exist and can be consumed that is definitely a good strategy.

One thing to keep in mind is that by default, many monitoring tools capture metrics for long term analysis. A common polling rate is every 1 minute or 5 minutes since they are expecting to store a lot of data (and this frequency can help with the manageability and scalability of that system).

As such, that "lower" resolution is generally not ideal for examining the impact of a load test. A typical load test runs for 1-- 2 hours. For such a short duration, higher capture intervals like 5, 10, or 20 seconds, are usually favored so a more detailed impact on the deployment's resources can be seen. This might be adjustable with most monitoring tools...not sure.
In cases where this higher resolution is not an option or maybe there is no monitoring tool even available, having the testing framework capture this type of data can be extremely valuable for the analysis.

Hope that helps.
Aaron

ErickTGG

Hey - Any reason why you haven't covered anything here with ArcGIS Monitor?

Is it that we can just create some filters in ArcGIS Monitor to view the same metrics?

Únete a la Conversación

Los miembros registrados pueden publicar, seguir actualizaciones y más. ¿Nuevo aquí? Regístrate para una cuenta gratuita.

Enlaces Rápidos

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.