Este artigo mostra a administradores, equipe de TI ou outros profissionais técnicos que dão suporte à implantação da utility network como interpretar informações de logs específicas para seus fluxos de trabalho. Este artigo é bastante técnico em alguns pontos e requer um forte entendimento dos conceitos e tecnologias usados para descrever a utility network.
Editar: Se você deseja fazer sua própria análise e parsing de logs, pode encontrar as ferramentas Python de exemplo usadas para gerar os gráficos neste artigo aqui.
Este artigo foi escrito para ajudar administradores, equipe de TI ou outros profissionais técnicos que dão suporte à implantação da utility network a entender como interpretar informações de logs específicas para seus fluxos de trabalho. Este artigo é bastante técnico em alguns pontos e requer um forte entendimento dos conceitos e tecnologias usados para descrever a utility network.
Para entender este artigo, você deve primeiro ter lido e estar familiarizado com o artigo Utility Network Diagnostics. Esse artigo descreve como capturar informações de logs para diferentes operações da utility network. Este artigo se baseia nesses conceitos fornecendo algumas dicas para interpretar esses logs e como métricas de desempenho podem ser extraídas para avaliar o desempenho do seu sistema. Esses logs não substituem ferramentas como ArcGIS Monitor, mas permitem que você investigue possíveis gargalos de desempenho.
Por que isso é importante?
Saber medir e avaliar o desempenho com precisão é uma habilidade importante, pois permite quantificar os impactos das suas decisões de modelagem de dados ou arquitetura. Você pode encontrar uma coleção de recursos que discutem o impacto dessas decisões na conclusão deste artigo.
Nota: Este artigo exibe capturas de tela de diferentes gráficos e logs, mas não inclui dados de exemplo para trabalhar. Os gráficos usam conjuntos de dados e escalas diferentes e não devem ser usados para tirar conclusões. Você deve realizar testes com seus próprios dados para tirar conclusões usando as técnicas descritas neste artigo. Os logs mostrados neste artigo são do ArcGIS Enterprise 12.1, portanto versões mais novas ou antigas podem mostrar mensagens diferentes. A redação específica e a estrutura dos arquivos de log mudam a cada versão, por isso é importante entender como interpretar logs em vez de memorizar mensagens específicas.
Outro ponto importante deste artigo é pensar em como os logs são usados. Eles são uma ferramenta importante para solução de problemas e também podem demonstrar o impacto que decisões de modelagem de dados, configuração ou até mesmo arquitetura podem ter no desempenho e na experiência do usuário final.
Os logs do servidor fornecem informações detalhadas que permitem medir o desempenho de operações específicas e, em muitos casos, também permitem correlacionar os impactos no desempenho a sub-redes específicas ou ao número de feições impactadas por essa operação. Por exemplo, considere a situação em que um usuário reclama que as sub-redes estão atualizando muito lentamente.
Uma avaliação normal de desempenho executaria a operação update subnetwork em todas as sub-redes do sistema, usando um único processo, para criar um gráfico que mostra os tempos de resposta retornados por esse servidor. Isso produz um gráfico como o seguinte:
Embora seja interessante ver a distribuição dos tempos de resposta, isso não fornece nenhuma visão sobre por que algumas respostas são melhores que outras ou o que requer investigação adicional. Em vez disso, essa abordagem trata cada resposta como igual, o que no caso das sub-redes não é verdade. Ao analisar os arquivos de log, você pode produzir gráficos que oferecem insights mais acionáveis.
Uma coisa fácil que você pode fazer para identificar sub-redes problemáticas para revisão é criar um gráfico que inclua o nome da sub-rede dos logs com seu tempo de resposta.
Isso permite encontrar uma sub-rede específica nos dados para investigação enquanto também dá uma ideia de como o sistema geral está se comportando. Isso facilita identificar suas sub-redes com melhor e pior desempenho, bem como quaisquer valores discrepantes.
Com um pouco mais de trabalho, você também pode extrair o número de feições em cada sub-rede dos arquivos de log. Isso permite criar um gráfico que usa o número de feições em cada sub-rede no eixo X.
Esse gráfico facilita ver a correlação entre o tamanho da rede e o tempo de resposta. Isso indica que na maioria das vezes as sub-redes que demoram mais para atualizar são maiores. Também permite ver que há algumas redes menores que estão demorando mais do que o esperado, permitindo focar sua atenção nelas.
Você pode levar essa abordagem ainda mais longe analisando informações mais detalhadas dos logs para ver os tempos associados a operações específicas dentro de cada sub-rede.
Esse gráfico permite ver as operações e sub-redes que estão levando mais tempo. Essas informações detalhadas permitem investigar quais passos podem ser tomados para melhorar o tempo dessas operações específicas.
Neste artigo você aprenderá algumas das principais considerações ao interpretar os tempos dos seguintes logs:
- Tracing usa o TraceLog
- Update Subnetwork usa o UpdateSubnetworkLog
- Export Subnetwork usa o ExportSubnetworkLog
- Enable Network Topology e Validate Network Topology usam o BuildLog
Antes de falar sobre os logs individuais, vamos discutir a importância do uso dessas ferramentas para ajudar a isolar e solucionar problemas de desempenho.
Isolando desempenho
Ao solucionar um problema de desempenho no ArcGIS Enterprise, é possível que ele seja causado por uma grande variedade de questões arquitetônicas, configurações ou até mesmo problemas nos dados. Se o problema investigado estiver focado no desempenho de uma única operação na utility network que não requer versionamento, uma boa forma de reduzir dependências e isolar o problema é copiar primeiro a utility network para uma nova geodatabase móvel.
Trabalhando com uma geodatabase móvel local, você pode focar no desempenho da utility network sem as variáveis adicionais associadas à arquitetura da implantação do ArcGIS Enterprise. Isso permite focar em um fluxo único sem versionamento.
O desempenho da utility network em um ambiente local não é equivalente ao ambiente empresarial. No entanto, isso permite determinar se um problema de desempenho é causado pelos dados e configuração da utility network ou pela arquitetura e configuração do ambiente.
Se o problema não for reproduzível no ambiente local, você ainda pode usar as informações obtidas nos testes locais para ajudar na investigação no ambiente empresarial. Você pode comparar os tempos e etapas dos logs detalhados entre a geodatabase local e a empresarial para ver se alguma etapa está demorando mais. Isso pode indicar um problema no banco de dados que pode ser investigado avaliando planos de desempenho usando ferramentas disponíveis para seu DBMS.
Você também pode comparar o tempo para cada operação relatado pelos logs do ArcGIS Server com os tempos de resposta relatados pelo cliente. Se houver grandes diferenças ou tempos inconsistentes entre eles, isso pode indicar um problema na comunicação entre cliente e servidor. Os gráficos abaixo mostram quais tempos são capturados por diferentes logs.
Medir o tempo de resposta do cliente inclui o tempo total gasto completando a solicitação nas camadas aplicação, servidor e dados da arquitetura. Isso geralmente não é útil para identificar a causa raiz do problema, mas continua importante para entender completamente o contexto e fluxo necessários para reproduzir o problema.
Os logs do ArcGIS Server permitem focar no tempo gasto nas camadas servidor e dados, além de fornecer contexto para cada solicitação junto com seu tempo decorrido.
Revisar desempenho na camada do banco também oferece insights úteis sobre problemas relacionados ao banco, mas carece do contexto das camadas cliente ou aplicação.
Copiar dados para uma geodatabase móvel local e capturar logs usando o Diagnostic Monitor no ArcGIS Pro é uma forma poderosa de isolar problemas de desempenho. Isso porque permite controlar o fluxo e contexto de cada operação enquanto mede seu desempenho com poucas dependências possíveis. Veja um diagrama do cenário abaixo.
Agora que você entende como e por que isolar problemas ao testar, vamos ver como analisar os logs da utility network em busca de informações sobre desempenho.
Trace Log
O Trace Log tem quatro seções importantes:
- Ambiente
- Parâmetros do Trace
- Etapas e tempos
- Estatísticas do índice da rede
Ao avaliar o desempenho geral do sistema, é comum observar o tempo total gasto em cada trace comparado ao número elementos retornados. O cenário mais comum para capturar isso é executar um trace subnetwork para cada sub-rede na utility network e medir quanto tempo levou versus número elementos em cada sub-rede.
O trace na mesma sub-rede retornará números diferentes dependendo se foi configurado pelo usuário ou usado pelas operações export subnetwork ou update subnetwork. Ao medir desempenho dos traces, deve-se observar performance dos traces das sub-redes usando sua configuração padrão durante update subnetwork. Se planeja usar export subnetwork, também deve medir performance do trace durante export usando sua configuração esperada.
Quando uma determinada sub-rede está com baixo desempenho, você pode então observar os tempos associados às etapas individuais para cada sub-rede versus número elementos em cada uma.
Ao analisar as várias etapas associadas a uma operação de trace, você começará a entender por que certos traces demoram mais e o impacto significativo que a configuração de um trace tem no desempenho geral.
Como exemplo, se você usar um gráfico como este para analisar o desempenho do trace após adicionar funções ou tipos específicos de resultado, poderá medir o custo de desempenho dessas mudanças específicas, cada uma exibida como sua própria operação com um custo associado.
Parâmetros do Ambiente e do Trace
A seção de configuração ajuda você a entender o contexto do trace. Ela comunica o tipo de trace, versão, os pontos de partida e a configuração do trace, junto com os tipos de resultado especificados para o trace. Todos esses parâmetros afetam o comportamento do trace. Fazer uma alteração em qualquer um deles produziria um resultado diferente e poderia afetar o desempenho.
Etapas e tempos
Esta seção do log inclui informações detalhadas sobre todas as operações realizadas durante o trace e quanto tempo cada uma levou. Algumas etapas também incluem informações sobre quantos recursos foram envolvidos naquela etapa do trace.
Ao analisar o tempo, a primeira coisa que você quer fazer é olhar quanto tempo o trace total levou, depois você quer olhar o tamanho dos resultados. O número de elementos percorridos e retornados está no final das etapas e tempos com as seguintes linhas:
O Tempo Total do Trace é fácil de entender; este é o tempo total gasto para realizar o trace. O número de elementos descobertos requer um pouco mais de consideração, pois inclui o número de elementos percorridos junto com o número de elementos no resultado.
Isso é importante porque muitos traces percorrem muitos elementos, mas retornam apenas um subconjunto dos resultados. Mesmo que um pequeno número de recursos seja retornado, o trace pode exigir que muitos recursos sejam analisados. Exemplos disso incluem traces upstream ou downstream, traces com uma barreira de filtro configurada ou traces executados durante update subnetwork para descobrir recursos em múltiplas subnetworks. Por isso, os elementos percorridos são frequentemente um melhor preditor de desempenho do que o tamanho do resultado.
Você também vai querer revisar as etapas individuais e seus tempos durante o trace. Esses detalhes mostrarão onde o tempo é gasto durante o trace.
Estatísticas do índice da rede
As estatísticas do índice da rede informam quanto da informação da rede foi carregada do banco de dados durante a análise. Esses logs são tipicamente usados apenas pelo suporte e desenvolvimento para diagnosticar problemas específicos.
Esta seção contém as seguintes estatísticas:
- Estatísticas da tabela Topology – Um resumo de quantas linhas foram lidas da topologia da rede.
- Estatísticas das tabelas Associations – Um resumo de quantas associações foram lidas.
- Estatísticas do motor Weight – Um resumo de quantos atributos da rede foram lidos.
- Estatísticas do gerenciador de memória – Um resumo da memória usada.
Se você decidir aprofundar nas estatísticas deste relatório, pode notar que nem todos os atributos da rede são reportados na seção de estatísticas do motor Weight. Isso ocorre porque atributos da rede armazenados in-line são armazenados dentro das tabelas topology e são incluídos quando a conectividade para o recurso é acessada no banco de dados. Cada atributo da rede out-of-line lido do índice da rede tem um pequeno custo associado, geralmente não mais que alguns milissegundos para uma rede pequena. No entanto, quando muitos atributos out-of-line são lidos ou quando a rede é muito maior, o custo pode se tornar perceptível.
Esta é a razão pela qual você deve considerar armazenar os atributos da rede necessários para a maioria dos seus traces in-line, especialmente aqueles referenciados pela definição da sua subnetwork. Por que nem todos os atributos da rede são armazenados in-line? Porque há uma quantidade limitada de armazenamento disponível para atributos in-line, então você deve decidir quais atributos são mais importantes e garantir que eles sejam armazenados in-line. Você também notará que atributos armazenados in-line não aparecem nas estatísticas do índice da rede.
Ao tentar comparar resultados entre dois testes, você também pode olhar para cache misses para determinar quanto estava disponível na memória (em cache) em oposição às linhas lidas do banco de dados.
Ao tentar comparar desempenho entre diferentes traces ou operações, é importante prestar atenção ao número de cache misses. Um trace executado inteiramente na memória (hot cache) terá melhor desempenho do que o mesmo trace que precisa carregar informações de conectividade do banco de dados (cold cache).
Não há muito que você possa fazer para controlar isso nos fluxos de trabalho dos usuários, mas é importante considerar ao configurar uma metodologia consistente de testes para que você possa comparar com precisão os resultados dos diferentes testes. A maneira mais conservadora e consistente de medir resultados é garantir que todos os testes sejam realizados contra um cold cache.
Log Update Subnetwork
Ao avaliar o desempenho do update subnetwork, você vai querer começar olhando o Log Update Subnetwork criado durante a operação update subnetwork. Além disso, frequentemente será necessário revisar o Trace Log associado a cada subnetwork, já que isso pode representar a maior parte do tempo gasto atualizando uma subnetwork.
Nota: Ao revisar o Trace Log para update subnetwork você pode notar que as etapas e tempos são diferentes daqueles ao executar apenas um trace. Isso depende da configuração da sua rede, mas você verá mais tempo gasto encontrando elementos em múltiplas subnetworks (para redes com propagação), tempo gasto recuperando geometria para calcular a linha da subnetwork, assim como tempo gasto calculando funções para a linha agregada.
Como no Trace Log, há três seções no log update subnetwork.
- Ambiente
- Parâmetros da Subnetwork
- Etapas e tempos
- Estatísticas do índice da rede
Ao avaliar o desempenho do update subnetwork você considerará as seguintes informações:
- Quanto tempo levou para atualizar a subnetwork?
- Qual era o tamanho da subnetwork sendo atualizada?
- Quantos recursos foram atualizados?
Os dois primeiros são facilmente descobertos no log; o último requer ler o log para descobrir quantos recursos foram alterados.
Ao avaliar o desempenho geral do sistema, normalmente você observará quanto tempo leva para atualizar cada subnetwork no sistema versus o número de recursos na subnetwork.
Ao realizar essa análise você pode considerar três cenários diferentes:
- Quanto tempo leva para realizar a primeira operação update subnetwork?
- Quanto tempo leva para atualizar uma subnetwork quando nada mudou?
- Quanto tempo leva para atualizar uma subnetwork quando um número razoável de recursos mudou?
Normalmente você vai querer focar em quanto tempo leva para executar update subnetwork contra um número razoável de edições, pois é isso que os usuários experimentarão em seus fluxos diários. A primeira atualização é importante porque é a mais demorada e deve ser realizada quando o sistema é implantado. O cenário sem mudanças é interessante porque representa o melhor caso para desempenho.
Quando encontrar uma subnetwork com desempenho abaixo do esperado, você pode olhar os tempos das etapas individuais para identificar se há alguma etapa específica que consome a maior parte do tempo.
Se comparar o tempo gasto executando um trace durante uma operação update subnetwork com um trace normal em uma subnetwork, geralmente encontrará que o trace executado durante update subnetwork leva mais tempo. Isso ocorre porque update subnetwork realiza trabalho adicional para carregar geometrias para agregar, calcular funções resumidas e em alguns casos encontrar elementos em múltiplas subnetworks.
Parâmetros do Ambiente e da Subnetwork
Ao revisar a seção de configuração do log você deve prestar atenção especial às seguintes configurações:
- Nome da Versão
- Modo Edição
- Nome Tier
O nome da versão e modo edição são importantes porque o comportamento e tempo necessário para atualizar a subnetwork podem ser diferentes dependendo do modo edição usado e se ocorreu na versão padrão ou nomeada. Você pode aprender mais sobre essas considerações no Entendendo Subnetworks: Modo edição artigo. Em resumo, quando o modo edição está definido como ‘with events’ você incorre em custos adicionais de desempenho devido às regras de atributo; quando está ‘without events’ desligado em uma versão nomeada, talvez não esteja atualizando todos os recursos na subnetwork.
Também é importante considerar o nome tier ao analisar desempenho porque a configuração do tier controla o comportamento do update subnetwork em relação à criação ou atualização da linha da subnetwork, diagramas da rede etc.
Etapas e tempos
Ao olhar as etapas e tempos, você está principalmente preocupado com as seguintes seções:
- Trace
- As várias etapas update (Connectivity, Content etc.)
- Gerenciamento da linha da subnetwork
- Gerenciamento dos diagramas da rede
- Total
Você vai olhar no Trace para ver quanto tempo ele levou e principalmente quantos recursos foram descobertos como parte da subnetwork.
Em seguida, verá quanto tempo foi gasto atualizando os vários atributos no banco de dados que rastreiam as informações persistidas da subnetwork (nome da subnetwork, está conectado etc.).
O tempo gasto gerenciando a linha da subnetwork e os diagramas geralmente é relativamente pequeno. Mas quando eles estão consumindo muito tempo pode ser necessário revisar as configurações desses itens.
A linha Total informa quanto tempo levou no total para atualizar a subnetwork.
Estatísticas do índice da rede
As considerações ao revisar as estatísticas do índice da rede para update subnetwork são as mesmas usadas no Trace Log.
Log Exportar
Ao avaliar o desempenho do exportar subnetwork você considera três coisas:
- Quais tipos de resultado, atributos etc. foram exportados?
- Quanto tempo levou para obter todas as informações solicitadas pelo trace para exportação?
- Quanto tempo levou para gerar o arquivo?
Para responder a essas perguntas, você deve olhar principalmente o Export Log. Há um TraceLog gerado para o trace que é executado como parte da operação de exportação da sub-rede, caso precise de uma análise mais detalhada do tempo gasto durante essa operação.
Dentro do Export Log, existem cinco seções diferentes:
- Ambiente
- Parâmetros da Sub-rede
- Parâmetros de Exportação
- Etapas e seus tempos
- Estatísticas do índice de rede
Ao avaliar o desempenho geral da exportação da sub-rede, você quer comparar o tempo que levou para executar a exportação da sub-rede com o número de feições sendo exportadas. No entanto, ao contrário do TraceLog e do UpdateSubnetworkLog, ele não inclui uma contagem de quantas feições foram retornadas pelo trace.
A contagem de feições pode, entretanto, ser extraída do TraceLog.
Quando você encontrar uma sub-rede com desempenho inferior durante a operação de exportação, você vai querer verificar onde o tempo está sendo gasto no export log. Se a maior parte do tempo for gasta no trace, então você vai querer revisar o trace log. Ao fazer isso, muitas vezes é útil comparar isso com o tempo gasto durante um trace normal na sub-rede (que não inclui nenhum tipo de resultado ou funções).
Essa abordagem permite identificar quanto tempo é gasto durante o trace na exportação da sub-rede obtendo cada tipo de resultado (conectividade, elementos de feição, etc.) junto com quanto tempo foi gasto executando o trace. O trace durante a exportação sempre levará mais tempo que um trace regular porque deve ler informações adicionais do banco de dados. Olhar os detalhes do trace log durante a exportação permite ver quanto tempo é gasto obtendo cada tipo de resultado.
É por isso que é importante que você só exporte os atributos e outras informações que são necessárias, porque o custo de exportar informações desnecessárias pode ser alto.
Ambiente e parâmetros
A exportação da sub-rede tem muitas opções que controlam o que você pode exportar. No entanto, quanto mais informações você incluir na exportação, mais longo será o trace usado para reunir todas as informações. Quanto mais informações você incluir na exportação, maiores serão os arquivos e mais tempo levará para gerar e baixar os arquivos.
Você pode ver quais informações um usuário especificou para incluir em sua exportação olhando a seção de parâmetros de exportação do relatório. Isso permite ver quais tipos de resultados foram incluídos junto com quantos atributos de rede, campos de resultado (para feições) e campos de registros relacionados (para registros relacionados) foram selecionados.
Incluir muitos atributos das feições e registros relacionados requer fazer consultas adicionais ao banco de dados, o que pode adicionar mais tempo ao trace para obter essa informação. Além disso, selecionar muitos atributos pode aumentar drasticamente o tamanho do arquivo. Incluir todos os atributos da rede para uma sub-rede pode dobrar o tamanho do arquivo e o tempo que leva para exportar a sub-rede. Incluir atributos de muitas tabelas diferentes terá um efeito negativo ainda maior no desempenho.
Etapas e tempos
Há menos etapas para analisar no log da exportação da sub-rede. Na maioria dos casos, o trace será o custo mais alto durante a exportação da sub-rede. No entanto, se você vir uma grande quantidade de tempo gasto nas etapas Process/Write JSON, isso indica que o arquivo é grande e está demorando para serializar, baixar e persistir.
Estatísticas do índice de rede
As considerações para revisar as estatísticas do índice de rede para a exportação da sub-rede são as mesmas do Trace Log.
Build Log
O formato do build log é diferente dos demais logs diagnósticos da utility network porque é projetado para ser um log incremental gerado durante sessões potencialmente longas. Por causa disso, cada linha no build log informa o tempo que levou para completar a etapa, o tempo total gasto até aquele ponto e a quantidade de memória usada naquele momento.
O mesmo formato de arquivo log é usado para as três operações de build:
- Enable Network Topology
- Disable Network Topology
- Validate Network Topology
Por isso, você pode notar que a numeração das etapas em alguns logs pode parecer pular certas etapas. Isso ocorre porque nem todas as etapas se aplicam a todas as operações.
Ao revisar os logs você deve focar nas seguintes seções
- Ambiente
Etapas e seus tempos
- Configuração do build da rede
- Processamento pós-build
- Estatísticas do índice de rede
Ao avaliar o desempenho, você deve considerar qual tipo de build está ocorrendo, quantos atributos da rede são processados, quanta memória/espaço em disco disponível há, se alguma análise foi realizada para identificar sub-redes afetadas pela validação (processamento pós-build), e quantas feições são processadas. A maior parte dessas informações está disponível nas seções ambiente e configuração do build da rede no log.
Para Enable Network Topology e Disable Network Topology, você está principalmente preocupado com throughput, uso de memória e uso de disco. Quanto mais você puder depender da memória para construir a topologia da rede, mais rápido será; mas para grandes conjuntos de dados isso não é realista. Nesses casos, o build começará a gravar informações no disco; nesse ponto você precisará garantir que o disco configurado seja rápido (idealmente um SSD) e que haja espaço suficiente no disco para armazenar os arquivos temporários.
Para Validate Network Topology, você está principalmente preocupado com o tempo total que levou para construir a rede já que um usuário normalmente chama Validate Network Topology e você quer minimizar o tempo que ele espera. Se você notar muito tempo gasto no processamento pós-build, então vai querer se familiarizar com o artigo Understanding Subnetworks Status. Esse comportamento é controlado pela definição da sub-rede para cada tier na rede e pode ser modificado mesmo depois que você tenha implantado sua utility network. Utility networks configuradas para manter um campo status em suas sub-redes devem realizar processamento pós-build durante Validate Network Topology para encontrar as sub-redes afetadas pela validação para que possam ser marcadas como sujas.
Ambiente e configuração do build da rede
A extensão validada é mostrada na seção ambiente do build log; essa extensão só faz sentido ao avaliar Validate Network Topology. Isso porque Enable Network Topology e Disable Network Topology sempre rodam na extensão completa da rede.
As etapas do build da rede, junto com o nome do arquivo log, mostrarão o tipo de build realizado. Você também pode ver quantos atributos da rede, memória e espaço em disco estavam disponíveis quando o processo começou. Se a quantidade de memória usada durante o build exceder a quantidade disponível, então o processo começará a gravar no disco e ficará mais lento.
Etapas e seus tempos
Existem muitas etapas durante o processo de build da rede; embora nem todas sejam descritas aqui, você deve ter em mente os seguintes pontos ao revisar os logs:
- Quanta informação foi processada durante esta etapa?
- Quanta informação foi criada durante esta etapa?
- Quanto tempo/memória esta etapa usou?
Cada etapa normalmente informa o tempo total que levou para completar na última mensagem dessa etapa.
Você pode encontrar o tempo total que toda a operação levou olhando a última linha do arquivo log.
Para identificar a quantidade de memória usada você precisará comparar a memória total reportada na primeira mensagem do log dessa etapa com a memória total reportada na última mensagem dessa etapa.
Estatísticas do índice de rede
Como o processo de build da rede popula o índice da rede, esta seção pode ser interessante para entender quanta informação as tabelas do sistema leram, escreveram ou criaram durante o processo. No entanto, não há muito que você possa fazer para influenciar esses números depois que tiver implantado uma utility network.
Se você estiver no início de um projeto, poderá ver os impactos da quantidade de atributos da rede que possui e usar essa oportunidade para garantir que exige todos os atributos necessários no modelo que está construindo. Se não precisar dos atributos da rede para nenhum fluxo de trabalho e estiver no início do projeto podendo ainda removê-los do seu modelo, considere fazer isso. Você sempre pode adicionar um atributo à rede depois; mas uma vez implantado, ele não pode ser removido.
Se estiver considerando continuar modelando registros relacionados como registros relacionados ou modelá-los como objetos não espaciais com conectividade e/ou contenção, poderá ver quanto tempo leva construir a rede incorporando esses objetos não espaciais adicionais na rede.
Conclusão
Agora que leu este artigo, deve estar familiarizado com como interpretar os logs das quatro principais operações da utility network. Você pode começar a executar testes de desempenho e interpretar os resultados em nível granular. Ao projetar sua arquitetura e tomar decisões importantes sobre modelagem de dados, poderá medir o impacto dessas decisões no seu desempenho.
Para uma abordagem mais sistêmica na captura e medição dos números de desempenho, talvez queira usar uma ferramenta como Extract Log Files, para combinar logs em um banco de dados. Os gráficos neste artigo foram criados usando uma abordagem onde números de desempenho foram extraídos de cada arquivo log usando expressões regulares e usados para criar visualizações.
Esses arquivos log são importantes porque fornecem uma medição precisa do tempo em que o servidor está realizando operações específicas. Eles são extremamente valiosos para avaliar uma única operação; entretanto, não fornecem uma visão completa. A análise de desempenho deve ser feita holisticamente, considerando não apenas o desempenho da utility network mas também o impacto que toda arquitetura tem no desempenho assim como como o sistema funciona sob carga.
Para exemplos sobre como realizar uma abordagem mais holística em testes e design visite o ArcGIS Architecture Center.
Para exemplos sobre como modelar registros relacionados pode afetar desempenho consulte o artigo Modeling related data in a utility network
Para exemplos de como a configuração do modo de edição da sua sub-rede pode afetar o desempenho da atualização da sub-rede, leia o Understanding Subnetwork Edit Mode artigo.
Para exemplos de como a configuração de gerenciamento de status da sua sub-rede pode afetar o desempenho da validação da topologia da rede, leia o Understanding Subnetwork Status artigo.
