Este artículo muestra a administradores, personal de TI u otro personal técnico que apoya el despliegue de utility network cómo interpretar la información de los registros específica para sus flujos de trabajo. Este artículo es muy técnico en algunos puntos y requiere un sólido entendimiento de los conceptos y tecnologías usados para describir la utility network.
Editar: Si deseas realizar tu propio análisis y procesamiento de registros, puedes encontrar las herramientas de ejemplo en Python usadas para generar los gráficos en este artículo aquí.
Este artículo fue escrito para ayudar a administradores, personal de TI u otro personal técnico que apoya el despliegue de utility network a entender cómo interpretar la información de los registros específica para sus flujos de trabajo. Este artículo es muy técnico en algunos puntos y requiere un sólido entendimiento de los conceptos y tecnologías usados para describir la utility network.
Para entender este artículo primero debes haber leído y estar familiarizado con el artículo Utility Network Diagnostics. Ese artículo describe cómo capturar información de registros para diferentes operaciones de utility network. Este artículo se basa en esos conceptos proporcionando algunos consejos para interpretar estos registros y cómo se pueden extraer métricas de rendimiento para evaluar el desempeño de tu sistema. Estos registros no reemplazan herramientas como ArcGIS Monitor pero te permiten profundizar e investigar posibles cuellos de botella en el rendimiento.
¿Por qué es esto importante?
Saber cómo medir y evaluar el rendimiento con precisión es una habilidad importante, ya que te permite cuantificar los impactos de tus decisiones sobre modelado de datos o arquitectura. Puedes encontrar una colección de recursos que discuten el impacto de estas decisiones al final de este artículo.
Nota: Este artículo muestra capturas de pantalla de diferentes gráficos y registros pero no incluye datos de ejemplo para trabajar. Los gráficos usan diferentes conjuntos y escalas de datos y no deben usarse para sacar conclusiones. Debes realizar pruebas con tus propios datos para sacar conclusiones usando las técnicas descritas en este artículo. Los registros mostrados son de ArcGIS Enterprise 12.1, por lo que versiones más nuevas o antiguas pueden mostrar mensajes diferentes. La redacción y estructura específica de los archivos de registro cambia con cada versión, por eso es importante entender cómo interpretar los registros en lugar de memorizar mensajes específicos.
Otra conclusión importante de este artículo es pensar en cómo se usan los registros. Son una herramienta importante para solucionar problemas, y también pueden demostrar el impacto que las decisiones sobre modelado de datos, configuración o incluso arquitectura pueden tener en el rendimiento y la experiencia del usuario final.
Los registros del servidor proporcionan información detallada que te permite medir el rendimiento de operaciones específicas, y en muchos casos también permiten correlacionar los impactos en el rendimiento con subredes específicas o con la cantidad de entidades afectadas por esa operación. Por ejemplo, considera la situación donde un usuario se queja que las subredes se actualizan demasiado lento.
Una evaluación normal del rendimiento ejecutaría la operación actualizar subred contra todas las subredes del sistema, usando un solo proceso, para crear un gráfico que muestre los tiempos de respuesta devueltos por este servidor. Esto produce un gráfico como el siguiente:
Aunque es interesante ver la distribución de tiempos de respuesta, no proporciona ninguna idea sobre por qué algunas respuestas son mejores que otras o qué requiere una investigación más profunda. En cambio, este enfoque trata cada respuesta como igual, lo cual no es cierto en el caso de las subredes. Al analizar los archivos de registro, puedes producir gráficos que ofrecen información más útil.
Una cosa sencilla que puedes hacer para identificar subredes problemáticas para revisión es crear un gráfico que incluya el nombre de la subred del registro junto con su tiempo de respuesta.
Esto te permite encontrar una subred específica en los datos para investigar mientras también te da una idea del comportamiento general del sistema. Esto facilita identificar tus subredes con mejor y peor rendimiento, así como cualquier valor atípico.
Con un poco más de trabajo, también puedes analizar la cantidad de entidades en cada subred desde los archivos del registro. Esto te permite crear un gráfico que use la cantidad de entidades en cada subred en el eje X.
Este gráfico facilita ver la correlación entre tamaño de red y tiempo de respuesta. Esto indica que la mayoría del tiempo, las subredes que tardan más en actualizarse son más grandes. También permite ver que hay algunas redes pequeñas que tardan más de lo esperado, permitiéndote enfocar tu atención en ellas.
Puedes llevar este enfoque aún más lejos analizando información más detallada desde los registros para ver los tiempos asociados con operaciones específicas dentro de cada subred.
Este gráfico te permite ver las operaciones y subredes que están tomando más tiempo. Esta información detallada te permite investigar qué pasos se pueden tomar para mejorar el tiempo de esas operaciones específicas.
En este artículo aprenderás algunas consideraciones clave al interpretar los tiempos para los siguientes registros:
- Tracing usa TraceLog
- Update Subnetwork usa UpdateSubnetworkLog
- Export Subnetwork usa ExportSubnetworkLog
- Enable Network Topology y Validate Network Topology usan BuildLog
Antes de hablar sobre los registros individuales, discutamos la importancia del uso de estas herramientas para ayudar a aislar y solucionar problemas de rendimiento.
Aislar el rendimiento
Al solucionar un problema de rendimiento en ArcGIS Enterprise, es posible que el problema sea causado por una amplia variedad de problemas arquitectónicos, configuraciones o incluso datos. Si el problema que investigas está enfocado en el rendimiento de una sola operación en utility network que no requiere versionado, una buena forma para reducir dependencias y aislar el problema es copiar primero la utility network a una nueva geodatabase móvil.
Al trabajar con una geodatabase móvil local, puedes enfocarte en el rendimiento mismo del utility network sin las variables adicionales asociadas con la arquitectura del despliegue ArcGIS Enterprise. Esto te permite concentrarte en un flujo sencillo sin versionado ni múltiples usuarios.
El rendimiento del utility network en un entorno local no equivale al rendimiento en un entorno empresarial. Sin embargo, esto te permite determinar si un problema se debe a los datos y configuración del utility network o a la arquitectura y configuración del entorno.
Si el problema no se reproduce en el entorno local, aún puedes usar la información obtenida allí para informar tu investigación en enterprise. Puedes comparar los tiempos y pasos detallados entre la geodatabase local y la empresarial para ver si algún paso tarda más. Esto podría indicar un problema con la base datos que puedes investigar evaluando planes usando herramientas disponibles para tu DBMS.
También puedes comparar el tiempo reportado por los registros ArcGIS Server con los tiempos reportados por el cliente. Si hay grandes diferencias o tiempos inconsistentes entre ambos, esto podría indicar un problema comunicación entre cliente y servidor. Las gráficas abajo muestran qué tiempos capturan diferentes registros.
Medir tiempo respuesta cliente incluye todo el tiempo empleado completando la solicitud en aplicación, servidor y capa datos dentro arquitectura. Esto a menudo no ayuda a identificar causa raíz pero sigue siendo importante para entender contexto completo y flujo necesario para reproducir problema.
Los registros ArcGIS Server permiten enfocarte en tiempo empleado en servidor y capa datos mientras proveen contexto adicional sobre cada solicitud además del tiempo tomado.
Revisar rendimiento a nivel base datos también ofrece información útil sobre problemas especialmente relacionados con base datos pero carece contexto cliente o capa aplicación.
Copiar datos a geodatabase móvil local y capturar registros usando Diagnostic Monitor en ArcGIS Pro es una forma poderosa para aislar problemas rendimiento porque te permite controlar flujo contexto cada operación mientras mides su desempeño con mínimas dependencias posibles. Puedes ver diagrama del escenario abajo.
Ahora que entiendes cómo y por qué aislar problemas rendimiento al probar, veremos cómo analizar logs utility network para obtener información sobre desempeño.
Registro Trace Log
Trace Log tiene cuatro secciones importantes:
- Entorno
- Parámetros Trace
- Pasos y tiempos
- Estadísticas índice red
Al evaluar desempeño general sistema es común observar tiempo total tomado por cada trace comparado con número elementos devueltos. El escenario más común para capturar esto es ejecutar trace subred para cada subred dentro utility network luego medir tiempo tomado versus número elementos dentro cada subred.
El trace sobre misma subred devolverá números diferentes según si es trace configurado por usuario o trace usado por operaciones export subnetwork o update subnetwork. Al medir desempeño traces debes observar desempeño traces subred usando configuración estándar durante update subnetwork. Si planeas usar export subnetwork también debes planear medir desempeño trace durante export usando configuración esperada.
Cuando una subred particular tiene bajo desempeño puedes observar entonces tiempo asociado a pasos individuales por cada subred versus número elementos dentro cada subred.
Al observar los diversos pasos asociados con una operación de trace, comenzarás a entender por qué ciertos traces tardan más y el impacto significativo que tiene la configuración de un trace en el rendimiento general.
Por ejemplo, si usas un gráfico como este para analizar el rendimiento del trace después de agregar funciones o tipos de resultados específicos, podrás medir el costo de rendimiento de esos cambios específicos, cada uno mostrado como su propia operación con un costo asociado.
Parámetros del entorno y del Trace
La sección de configuración te ayuda a entender el contexto del trace. Comunica el tipo de trace, la versión, los puntos de inicio y la configuración del trace, junto con los tipos de resultados especificados para el trace. Todos estos parámetros afectan el comportamiento del trace. Cambiar cualquiera de ellos produciría un resultado diferente y podría afectar el rendimiento.
Pasos y tiempos
Esta sección del registro incluye información detallada sobre todas las operaciones realizadas durante el trace y cuánto tiempo tomó cada una. Algunos pasos también incluyen información sobre cuántas features estuvieron involucradas en ese paso del trace.
Al analizar el tiempo, lo primero que quieres hacer es ver cuánto tiempo tomó el trace total, luego quieres observar el tamaño de los resultados. El número de elementos recorridos y devueltos está al final de los pasos y tiempos con las siguientes líneas:
El Tiempo Total del Trace es fácil de entender; es el tiempo total que tomó realizar el trace. El número de elementos descubiertos requiere un poco más de consideración ya que incluye la cantidad de elementos recorridos junto con la cantidad de elementos en el resultado.
Esto es importante porque muchos traces recorrerán muchos elementos pero solo devolverán un subconjunto de los resultados. Aunque se devuelva un pequeño número de features, el trace puede requerir analizar muchas features. Ejemplos incluyen traces aguas arriba o aguas abajo, traces con una barrera filtro configurada o traces ejecutados durante update subnetwork para descubrir features en múltiples subnetworks. Por esto, los elementos recorridos suelen ser un mejor predictor del rendimiento que el tamaño del resultado.
También querrás revisar los pasos individuales y sus tiempos durante el trace. Estos detalles te mostrarán dónde se invierte el tiempo durante el trace.
Estadísticas del índice de red
Las estadísticas del índice de red te informan cuánta información de la red se cargó desde la base de datos durante el análisis. Estos registros suelen ser usados solo por soporte y desarrollo para diagnosticar problemas específicos.
Esta sección contiene las siguientes estadísticas:
- Estadísticas de la tabla Topology – Un resumen de cuántas filas se leyeron de la topología de red.
- Estadísticas de las tablas Associations – Un resumen de cuántas asociaciones se leyeron.
- Estadísticas del motor Weight – Un resumen de cuántos atributos de red se leyeron.
- Estadísticas del gestor de memoria – Un resumen de la memoria utilizada.
Si decides profundizar en las estadísticas en este informe, puedes notar que no todos los atributos de red se reportan en la sección Estadísticas del motor Weight. Esto es porque atributos de red almacenados in-line se almacenan dentro de las tablas topology y se incluyen cuando se accede a la conectividad para la feature desde la base de datos. Cada atributo fuera-de-línea leído desde el índice de red tiene un pequeño costo asociado, usualmente no más que unos pocos milisegundos para una red pequeña. Sin embargo, cuando se leen muchos atributos fuera-de-línea o cuando la red es mucho más grande, el costo puede volverse notable.
Esta es la razón por la que deberías considerar almacenar los atributos necesarios para la mayoría de tus traces in-line, especialmente aquellos referenciados por tu definición subnetwork. ¿Por qué no todos los atributos están almacenados in-line? Porque hay una cantidad limitada de almacenamiento disponible para atributos in-line, así que debes decidir cuáles son los más importantes y asegurarte que estén almacenados in-line. También notarás que los atributos almacenados in-line no aparecen en las estadísticas del índice de red.
Al intentar comparar resultados entre dos pruebas, también puedes mirar las fallas en caché para determinar cuánto estaba disponible en memoria (cacheado) en lugar de filas leídas desde la base de datos.
Al intentar comparar rendimiento entre diferentes traces u operaciones, es importante prestar atención al número de fallas en caché. Un trace ejecutado completamente desde memoria (hot cache) tendrá mejor rendimiento que el mismo trace que debe cargar información desde la base de datos (cold cache).
No hay mucho que puedas hacer para controlar esto en flujos de trabajo del usuario, pero es importante considerarlo al establecer una metodología consistente para pruebas para poder comparar resultados con precisión entre diferentes pruebas. La forma más conservadora y consistente para medir resultados es asegurarse que todas las pruebas se realicen contra una cold cache.
Registro Update Subnetwork
Al evaluar el rendimiento del update subnetwork, querrás comenzar mirando el Registro Update Subnetwork creado durante la operación update subnetwork. Además, a menudo querrás revisar el Trace Log asociado con cada subnetwork, ya que esto puede explicar gran parte del tiempo invertido en actualizar una subnetwork.
Nota: Al revisar el Trace Log para update subnetwork puedes notar que los pasos y tiempos son diferentes a si simplemente ejecutas un trace. Esto depende de tu configuración de red, pero verás más tiempo invertido encontrando elementos en múltiples subnetworks (para redes con propagación), tiempo gastado recuperando geometría para calcular la línea subnetwork, así como tiempo gastado calculando funciones para la línea agregada.
Como en Trace Log, hay tres secciones en el registro update subnetwork.
- Entorno
- Parámetros Subnetwork
- Pasos y tiempos
- Estadísticas índice red
Al evaluar el rendimiento del update subnetwork considerarás la siguiente información:
- ¿Cuánto tiempo tomó actualizar la subnetwork?
- ¿Qué tan grande era la subnetwork actualizada?
- ¿Cuántas features fueron actualizadas?
Los dos primeros se descubren fácilmente en el registro; el último requiere leerlo para saber cuántas features cambiaron.
Al evaluar el rendimiento general del sistema normalmente observarás cuánto tiempo toma actualizar cada subnetwork en relación con la cantidad de features en esa subnetwork.
Al realizar este análisis puedes considerar tres escenarios diferentes:
- ¿Cuánto tarda realizar la primera operación update subnetwork?
- ¿Cuánto tarda actualizar una subnetwork cuando nada ha cambiado?
- ¿Cuánto tarda actualizar una subnetwork cuando un número razonable de features han cambiado?
Normalmente querrás enfocarte en cuánto tiempo toma ejecutar update subnetwork con un número razonable de ediciones, ya que esto es lo que los usuarios experimentarán en sus flujos diarios. La primera actualización es importante porque consume más tiempo y debe realizarse cuando se despliega el sistema. El escenario sin cambios es interesante porque representa el mejor caso para rendimiento.
Cuando encuentres una subnetwork con bajo rendimiento puedes mirar los tiempos individuales para identificar si hay algún paso particular que tome la mayor parte del tiempo.
Si comparas el tiempo invertido ejecutando un trace durante update subnetwork con un trace normal verás usualmente que el trace durante update subnetwork toma más tiempo. Esto es porque update subnetwork realiza trabajo adicional cargando geometrías para agregar, calculando funciones resumen y en algunos casos encontrando elementos en múltiples subnetworks.
Parámetros Entorno y Subnetwork
Al revisar la sección configuración del registro debes prestar especial atención a las siguientes configuraciones:
- Nombre Versión
- Modo Edición
- Nombre Tier
El nombre versión y modo edición son importantes porque el comportamiento y tiempo que toma actualizar una subnetwork pueden variar según modo edición usado y si ocurrió en versión default o nombrada. Puedes aprender más sobre estas consideraciones en Understanding Subnetworks: Edit mode. En resumen, cuando modo edición está configurado ‘with events’ incurres costos adicionales por reglas atributo; cuando modo edición está ‘without events’ apagado en versión nombrada puede que no estés actualizando todas las features en la subnetwork.
También es importante considerar nombre tier al mirar rendimiento porque la configuración trace del tier controla comportamiento update subnetwork respecto a crear o actualizar línea subnetwork, diagramas red, etc.
Pasos y tiempos
Al observar pasos y tiempos te interesan principalmente las siguientes secciones:
- Trace
- Los varios pasos update (Connectivity, Content, etc.)
- Gestión línea subnetwork
- Gestión diagramas red
- Total
Verás Trace para saber cuánto tiempo tomó y lo más importante cuántas features fueron descubiertas como parte del subnetwork.
Luego verás cuánto tiempo se gastó actualizando varios atributos en base datos que rastrean info persistente subnetwork (nombre subnetwork, está conectado, etc.).
El tiempo invertido gestionando línea subnetwork y diagramas red suele ser relativamente pequeño. Pero si toman mucho tiempo puede ser necesario revisar configuraciones relacionadas.
La línea Total indica el tiempo total que tomó actualizar la subnetwork.
Estadísticas índice red
Las consideraciones para revisar estadísticas índice red para update subnetwork son iguales a las del Trace Log.
Registro Exportar
Al evaluar rendimiento exportar subnetwork consideras tres cosas:
- ¿Qué tipos resultado, atributos, etc., fueron exportados?
- ¿Cuánto tardó obtener toda la información solicitada por el trace para exportar?
- ¿Cuánto tardó generar el archivo?
Para responder a estas preguntas, principalmente observarás el Export Log. Se genera un TraceLog para el rastreo que se ejecuta como parte de la operación de exportación de subred si necesitas un desglose más detallado del tiempo empleado durante esa operación.
Dentro del Export Log hay cinco secciones diferentes:
- Entorno
- Parámetros de la subred
- Parámetros de exportación
- Pasos y sus tiempos
- Estadísticas del índice de red
Al evaluar el rendimiento general de la exportación de subred, quieres comparar el tiempo que tomó ejecutar la exportación de subred con el número de elementos que se están exportando. Sin embargo, a diferencia del TraceLog y UpdateSubnetworkLog, no incluye un conteo de cuántos elementos fueron devueltos por el rastreo.
Sin embargo, el conteo de elementos puede extraerse del TraceLog.
Cuando encuentres una subred con bajo rendimiento durante la operación de exportación, querrás ver dónde se está invirtiendo el tiempo en el export log. Si la mayor parte del tiempo se dedica al rastreo, entonces deberás revisar el trace log. Al hacer esto, a menudo es útil comparar este tiempo con el tiempo empleado durante un rastreo normal de subred (que no incluye ningún tipo de resultado o función).
Este enfoque te permite identificar cuánto tiempo se dedica durante el rastreo en la exportación de subred obteniendo cada tipo de resultado (conectividad, elementos del elemento, etc.) junto con cuánto tiempo se dedicó a ejecutar el rastreo. El rastreo durante la exportación siempre tomará más tiempo que un rastreo regular porque debe leer información adicional de la base de datos. Observar los detalles del trace log durante la exportación te permite ver cuánto tiempo se dedica a obtener cada tipo de resultado.
Por eso es importante que solo exportes los atributos y otra información que sea necesaria, porque el costo de exportar información innecesaria puede ser alto.
Entorno y parámetros
La exportación de subred tiene muchas opciones que controlan qué puedes exportar. Sin embargo, cuanta más información incluyas en la exportación, más tiempo tomará el rastreo utilizado para recopilar toda la información. Cuanta más información incluyas en la exportación, más grandes serán los archivos y más tiempo tomará generarlos y descargarlos.
Puedes ver qué información especificó un usuario para incluir en su exportación mirando la sección de parámetros de exportación del informe. Esto te permite ver qué tipos de resultados se incluyeron junto con cuántos atributos de red, campos de resultados (para elementos) y campos relacionados (para registros relacionados) fueron seleccionados.
Incluir muchos atributos de elementos y registros relacionados requiere hacer consultas adicionales a la base de datos, lo que puede añadir más tiempo al rastreo para obtener esta información. Además, seleccionar muchos atributos puede aumentar drásticamente el tamaño del archivo. Incluir todos los atributos de red para una subred puede duplicar el tamaño del archivo y el tiempo que toma exportar la subred. Incluir atributos de muchas tablas diferentes tendrá un efecto negativo aún mayor en el rendimiento.
Pasos y tiempos
Hay menos pasos para analizar en el registro de exportación de subred. En la mayoría de los casos, el rastreo será el costo más alto durante la exportación de subred. Sin embargo, si ves una gran cantidad de tiempo dedicado a los pasos Process/Write JSON, esto indica que el archivo es grande y está tomando mucho tiempo serializarse, descargarse y persistirse.
Estadísticas del índice de red
Las consideraciones para revisar las estadísticas del índice de red para la exportación de subred son las mismas que para el Trace Log.
Build Log
El formato del build log es diferente al resto de los registros diagnósticos del utility network porque está diseñado para ser un registro incremental generado durante sesiones potencialmente largas. Debido a esto, cada línea en el build log reporta la cantidad de tiempo que tomó completar el paso, el tiempo total transcurrido hasta ese punto y la cantidad de memoria usada en ese momento.
El mismo formato de archivo log se usa para las tres operaciones build:
- Enable Network Topology
- Disable Network Topology
- Validate Network Topology
Por esta razón, puedes notar que la numeración de pasos en algunos logs puede parecer saltarse ciertos pasos. Esto es porque no todos los pasos aplican a todas las operaciones.
Al revisar los logs quieres enfocarte en las siguientes secciones
- Entorno
Pasos y sus tiempos
- Configuración build network
- Procesamiento post build
- Estadísticas del índice de red
Al evaluar el rendimiento, debes considerar qué tipo de build está ocurriendo, cuántos atributos de red se procesan, cuánta memoria/espacio en disco disponible hay, si se realizó algún análisis para identificar subredes afectadas por la validación (procesamiento post build), y cuántos elementos se procesan. La mayoría de esta información está disponible en las secciones entorno y configuración build network del log.
Para Enable Network Topology y Disable Network Topology, te preocupan principalmente el rendimiento, uso de memoria y uso del disco. Cuanto más puedas depender de la memoria para construir la topología de red, más rápido será; pero para conjuntos grandes esto no es realista. En esos casos, el build comenzará a escribir información en disco; entonces necesitarás asegurarte que el disco configurado sea rápido (idealmente un SSD) y que haya suficiente espacio para almacenar archivos temporales.
Para Validate Network Topology te preocupa principalmente el tiempo total que tomó construir la red ya que típicamente un usuario llama a Validate Network Topology y quieres minimizar su espera. Si notas mucho tiempo dedicado al procesamiento post build, entonces querrás familiarizarte con el artículo Understanding Subnetworks Status. Este comportamiento está controlado por la definición subnetwork para cada nivel en la red y puede modificarse incluso después haber desplegado tu utility network. Las utility networks configuradas para mantener un campo status en sus subnetworks deben realizar procesamiento post build durante Validate Network Topology para encontrar las subredes afectadas por la validación y marcarlas como sucias.
Entorno y configuración build network
La extensión validada se muestra en la sección entorno del build log; esta extensión solo tiene sentido al evaluar Validate Network Topology. Esto es porque Enable Network Topology y Disable Network Topology siempre corren sobre toda la extensión completa de la red.
Los pasos build network junto con el nombre del archivo log mostrarán qué tipo build se realizó. También puedes ver cuántos atributos red, memoria y espacio disco estaban disponibles cuando comenzó el proceso. Si la memoria usada durante build excede la memoria disponible, entonces comenzará a escribir en disco y será más lento.
Pasos y sus tiempos
Hay muchos pasos durante el proceso build network; aunque no todos están descritos aquí debes tener en cuenta lo siguiente al revisar los logs:
- ¿Cuánta información fue procesada durante este paso?
- ¿Cuánta información fue creada durante este paso?
- ¿Cuánto tiempo/memoria usó este paso?
Cada paso típicamente reporta el tiempo total que tomó completar ese paso en su último mensaje.
Puedes encontrar el tiempo total que tomó toda la operación mirando la última línea del archivo log.
Para identificar cuánta memoria se usó necesitarás comparar la memoria total reportada durante el primer mensaje log del paso con la memoria total reportada durante el último mensaje log del paso.
Estadísticas del índice de red
Debido a que el proceso build network llena el índice red, esta sección puede ser interesante para entender cuánta información las tablas sistema leyeron, escribieron o crearon durante el proceso. Sin embargo, no hay mucho que puedas hacer para influir estos números una vez hayas desplegado una utility network.
Si estás al inicio de un proyecto podrás ver los impactos según cuántos atributos red tienes y usar esta oportunidad para asegurarte que requieres todos los atributos red que tiene tu modelo. Si no necesitas los atributos red para ningún flujo trabajo y estás al inicio aún puedes eliminarlos; considera hacerlo. Siempre puedes agregar un atributo red a una red pero una vez desplegado no puede eliminarse.
Si estás considerando si continuar modelando registros relacionados como registros relacionados o modelarlos como objetos no espaciales con conectividad y/o contención podrás ver cuánto tarda construir la red incorporando esos objetos no espaciales adicionales.
Conclusión
Ahora que has leído este artículo deberías estar familiarizado con cómo interpretar los logs para las cuatro operaciones principales del utility network. Puedes comenzar a realizar pruebas rendimiento e interpretar resultados a nivel granular. Al diseñar tu arquitectura y tomar decisiones importantes sobre modelado datos puedes medir impacto esas decisiones tienen sobre tu rendimiento.
Para un enfoque más sistémico capturando y midiendo números rendimiento quizás quieras usar una herramienta como Extract Log Files para combinar logs en una base datos. Los gráficos en este artículo fueron creados usando un enfoque donde números rendimiento fueron extraídos desde cada archivo log usando expresiones regulares y usados para crear visualizaciones.
Estos archivos log son importantes porque dan una medición precisa del tiempo que servidor realiza operaciones específicas. Son extremadamente valiosos para evaluar una sola operación; sin embargo no proporcionan toda la imagen completa. El análisis rendimiento debe hacerse holísticamente considerando no solo rendimiento utility network sino también impacto arquitectura completa sobre rendimiento así como cómo sistema funciona bajo carga.
Para ejemplos realizando un enfoque más holístico pruebas diseño visita ArcGIS Architecture Center.
Para ejemplos sobre cómo modelar registros relacionados puede afectar rendimiento consulta Modeling related data in a utility network artículo.
Para ejemplos de cómo la configuración del modo de edición de tu subred puede afectar el rendimiento de actualización de subred, lee el Understanding Subnetwork Edit Mode artículo.
Para ejemplos de cómo la configuración de gestión de estado de tu subred puede afectar el rendimiento de validación de la topología de red, lee el Understanding Subnetwork Status artículo.
