Projetando e Otimizando Serviços de Imagem para Análise de Alto Desempenho

DavidJohnson5

<\/HEAD>

Serviços de imagem não são apenas para fornecer imagens; eles também podem realizar análises dinâmicas em nível de pixel em múltiplos conjuntos de dados raster sobrepostos usando funções raster encadeadas.  Serviços de imagem oferecem desempenho extremamente rápido com imagens-fonte pré-processadas, especialmente quando servidas a partir de um cache de blocos (tile cache).  Serviços de imagem dinâmicos, por outro lado, podem não responder tão rapidamente devido às demandas adicionais de processamento que impõem ao servidor.  Alto desempenho é importante para serviços de imagem dinâmicos porque os dados são reprocessados automaticamente cada vez que o usuário move ou amplia o mapa.  Serviços de imagem dinâmicos normalmente produzem respostas em menos de um segundo para tipos simples de análise.  Mas análises mais complexas podem levar muito mais tempo dependendo da complexidade da cadeia de processamento e do número de conjuntos de dados de entrada envolvidos.  Como podemos obter melhor desempenho nessas situações?  Para responder a essa pergunta, realizei uma série de testes para ver como os seguintes fatores afetam o desempenho dos serviços de imagem dinâmicos:<\/P>

<\/P>

• Escala do mapa e resolução dos dados-fonte<\/LI><\/UL><\/UL>
  • Método de reamostragem<\/LI><\/UL><\/UL>
    • Formato e compressão dos dados-fonte<\/LI><\/UL><\/UL>
      • Projeção dinâmica (on-the-fly)<\/LI>
      • Tamanho da requisição<\/LI><\/UL><\/UL>

        
        Neste artigo apresento os resultados desses testes junto com algumas sugestões para maximizar o desempenho.  Minha máquina de teste é um computador desktop rodando Windows 7 SP1 e ArcGIS 10.2.1 com 18GB de RAM e um processador quad-core Intel Xeon W3550 rodando a 3 GHZ.  Os dados de teste foram armazenados em um disco rígido SATA vazio de 2 TB que foi desfragmentado e consolidado antes dos testes.   Os testes foram configurados para determinar os tempos médios de resposta dos serviços sob várias condições.  Por "tempo de resposta" entendo o tempo que um serviço leva para recuperar os dados-fonte, processá-los e transmitir uma imagem de saída.  O tempo de transmissão foi minimizado executando o aplicativo de teste diretamente na máquina do servidor.<\/P>

        <\/P>

        Esta informação é escrita pensando no usuário intermediário a avançado em GIS.  Presumo que o leitor tenha uma compreensão geral sobre serviços de imagem, dados raster e análise, funções raster, geoprocessamento, conjuntos mosaico (mosaic datasets), projeções cartográficas e cache de serviços de mapa.<\/P>

        <\/P>

        Escala do Mapa e Resolução dos Dados-Fonte<\/STRONG><\/P><\/P>Os pixels processados para análise por serviços de imagem dinâmicos geralmente não são idênticos aos pixels armazenados nos conjuntos de dados-fonte.  Em vez disso, os pixels dos dados-fonte são primeiro reamostrados dinamicamente para um novo tamanho baseado na escala atual do mapa.  Esta fórmula mostra a relação entre escala do mapa e tamanho da reamostragem quando as unidades do mapa dos dados são metros:<\/P><\/P>Tamanho do pixel reamostrado = escala do mapa * 0.0254\/96<\/A><\/P>

        <\/P>

        O tamanho do pixel reamostrado é análogo ao parâmetro "Analysis Cell Size" no Framework de Geoprocessamento e às vezes é referido como o "tamanho do pixel da requisição".  Conforme você dá zoom out para escalas menores do mapa, o tamanho do pixel reamostrado aumenta até que eventualmente o serviço reamostra a partir dos pixels nas pirâmides (pyramids).  Reamostrar a partir das pirâmides ajuda a manter o desempenho do serviço relativamente consistente em uma faixa de escalas do mapa.<\/P>

        <\/P>

        Gráfico 1. Desempenho de um serviço de imagem que realiza uma análise binária sobreposta em uma faixa de escalas do mapa.<\/P><\/DIV>O desempenho ainda varia dependendo da escala do mapa e tipicamente se parece com o gráfico 1.    Eu gerei esses resultados usando um aplicativo configurado para simular um único usuário movendo o mapa 100 vezes consecutivas em escalas específicas do mapa.  O gráfico mostra o tempo médio que o serviço levou para processar e transmitir as imagens de saída para diferentes escalas do mapa.  Este serviço particular foi configurado com um modelo (template) de função raster para realizar uma análise binária sobreposta em onze rasters sobrepostos em um conjunto mosaico (mosaic dataset).  Os tamanhos dos pixels dos conjuntos-fonte variaram entre 91,67 a 100 metros.  O modelo da função raster foi configurado para retornar um resultado binário, onde cada pixel da saída é classificado como "adequado" ou "inadequado" baseado nos parâmetros da análise.<\/P><\/P>Dê uma olhada nos três pontos ao longo do eixo horizontal onde o tempo de resposta cai abruptamente.  Nessas escalas do mapa, o tamanho do pixel reamostrado é igual ao tamanho dos pixels das pirâmides nos dados-fonte.  O tempo de processamento para reamostragem é menor nessas escalas porque há quase uma correspondência 1:1 entre pixels dos dados-fonte e pixels reamostrados.  Aplicativos clientes que usam este serviço específico verão tempos dramaticamente mais rápidos se forem limitados, por algum meio, apenas a essas escalas.  Uma forma de fazer isso é usar uma camada base em blocos (tiled basemap).  Aplicativos web que usam camadas base em blocos geralmente são limitados apenas a essas escalas do mapa.  O esquema mais usado para blocos é o esquema ArcGIS Online/Bing Maps/Google Maps (referido doravante como "esquema AGOL" por brevidade).  As linhas verticais vermelhas pontilhadas no gráfico indicam as escalas do mapa para os níveis 7 – 12 deste esquema.  Infelizmente essas escalas não estão muito próximas das escalas onde este serviço tem seu melhor desempenho.  Existem duas opções para alinhar pixels dos dados-fonte com as escalas do esquema em blocos:<\/P><\/P>Criar uma camada base personalizada com um esquema em blocos personalizado que corresponda aos tamanhos dos pixels dos dados.<\/LI>Amostrar ou reamostrar os dados para um tamanho de pixel que corresponda ao esquema em blocos da camada base.<\/LI><\/OL><\/OL>Gráfico 2. Desempenho do serviço binário sobreposto com diferentes tamanhos dos pixels dos dados-fonte<\/P><\/DIV>O eixo horizontal no gráfico 2 representa o "tamanho do pixel da requisição" ao invés da escala do mapa como no gráfico 1.  O gráfico laranja mostra os tempos de resposta de outro serviço configurado idêntico ao primeiro azul, exceto que usa conjuntos-fonte que foram ampliados (up-sampled) para pixels de 38 metros usando a ferramenta Resample<\/_A> do geoprocessamento.  Ampliar para pixels de 38 metros alinhou os tempos mais rápidos deste serviço com as escalas do esquema AGOL, resultando numa redução significativa no tempo de processamento nessas escalas, passando aproximadamente de 1,5 segundos para cerca de 0,5 segundos.  Além disso, note que o desempenho melhorou em quase todas as escalas exceto na maior delas.  Isso provavelmente se deve a ter todos os dados-fonte na mesma resolução (38m) ao invés das três anteriores (91,67m, 92,5m, 100m), e/ou porque os pixels dos dados-fonte também estão alinhados entre os conjuntos (conseguido definindo um ponto origem comum para cada raster reamostrado usando a configuração ambiental "Snap Raster").<\/P>

        <\/_p>

        P>Admitidamente, usar a ferramenta Resample para preparar dados para análise não é ideal porque resulta em dados gerados na segunda geração menos precisos que os originais.  Isso pode ser perfeitamente aceitável para aplicações destinadas a fornecer uma análise inicial em nível exploratório; todavia, é melhor gerar novos dados da primeira geração no tamanho desejado sempre que possível.  Por exemplo, se você tem acesso a polígonos classificatórios terrestres (land-class polygons), poderia usá-los para gerar um novo conjunto raster da primeira geração no tamanho desejado usando a ferramenta Polygon to Raster<\/_A>, ao invés de reamostrar um conjunto raster existente classificatório terrestre.<\/_p>
        P>Para determinar quanto o desempenho melhorou com pixels de 38 metros, calculei a variação percentual nos tempos médios das respostas para cada escala e fiz a média desses valores ao longo das múltiplas escalas.<\/_p>P> <\/_p>P>A ampliação dos dados-fonte para pixels de 38 metros reduziu os tempos das respostas em                           &nbspporcento!& nbsp ;38 metros não foi minha única opção neste exemplo . & nbsp ;Eu poderia ter escolhido um tamanho correspondente a uma das outras escalas do esquema em blocos . & nbsp ;A tabela seguinte lista todas as escalas do esquema AGOL , bem como os tamanhos correspondentes dos pixels nas unidades metros , pés e Graus Decimais.   As três colunas à direita fornecem valores sugeridos para amostragem de dados raster.  Essas sugestões não são definitivas.  Não é necessário amostrar seus dados exatamente nesses tamanhos recomendados.  O importante é escolher um tamanho que seja ligeiramente menor do que um dos tamanhos das escalas do esquema de ladrilhamento alvo.<\/P>

        <\/P>

        Escalas de Mapa e Tamanhos de Pixel para o esquema de ladrilhamento ArcGIS Online\/Bing Maps\/Google Maps<\/EM><\/P><\/A><\/P>

        <\/P>

        Aliás, combinar os tamanhos de pixel dos seus dados com um esquema de ladrilhamento de mapa base também é útil para fluxos de trabalho que envolvem imagens estáticas sobrepostas a um mapa base em ladrilhos.  <\/SPAN>Para esses casos, você pode construir visões gerais do conjunto de mosaicos para visualização em escalas menores em vez de pirâmides raster.  <\/SPAN>Uma das grandes vantagens das visões gerais do conjunto de mosaicos é que você pode definir o tamanho base do pixel das visões gerais, bem como o fator de escala para corresponder ao seu esquema de ladrilhamento alvo.  <\/SPAN>Dessa forma, você não precisa reamostrar os dados fonte para um novo tamanho base de pixel para atender a qualquer esquema de ladrilhamento específico.<\/P>
        Método de Reamostragem<\/STRONG><\/P><\/P><\/P>O

        método de reamostragem<\/A> <\/SPAN>especificado para uma solicitação do serviço de imagem também impacta o desempenho.  <\/SPAN>A escolha de qual usar deve ser baseada principalmente no tipo de dado usado na análise.  <\/SPAN>O Gráfico 3 mostra o desempenho do serviço de análise por sobreposição binária (com dados de 38 metros) com diferentes métodos de reamostragem.<\/P><\/A>

        Gráfico 3. Tempos de resposta do serviço de análise por sobreposição binária com diferentes métodos de reamostragem<\/P><\/DIV>

        <\/P>

        <\/P>

        <\/P>

        A reamostragem bilinear é o método padrão.  <\/SPAN>Aqui está como os tempos de resposta dos outros métodos se comparam à média bilinear nas cinco escalas de mapa testadas:<\/P>

        <\/A><\/P>

        
        Formato Raster<\/STRONG><\/P><\/P>O formato de armazenamento dos dados pode ter um enorme impacto no desempenho.  Por exemplo, o tempo de resposta do serviço de análise por sobreposição binária, em média em todas as escalas do mapa, foi 36% menor quando os dados foram armazenados no formato GeoTIFF versus raster gerenciado por geodatabase arquivo.  A seção

        Fontes e Formatos de Dados<\/A> do guia Image Management recomenda deixar os dados em seu formato original, a menos que estejam em um dos formatos com desempenho mais lento, como ASCII.  GeoTIFF com blocos internos é a escolha recomendada para reformatação porque fornece acesso rápido aos pixels para áreas retangulares que cobrem apenas um subconjunto do arquivo inteiro.Tipo e Compressão do Pixel<\/STRONG><\/P><\/P>O tipo do pixel determina a precisão dos valores armazenados nos dados e pode ter um enorme impacto no desempenho.  Em geral, tipos inteiros são mais rápidos que tipos ponto flutuante, e tipos com menor precisão são mais rápidos que tipos com maior precisão.  A compressão da imagem pode potencialmente aumentar ou reduzir o desempenho dependendo da situação.   Para mais informações sobre o efeito da compressão no tamanho do arquivo, consulte a seção Fontes e Formatos de Dados do guia Image Management.  Para avaliar o impacto do tipo e compressão do pixel no desempenho dos dados armazenados em um disco rígido local, testei um grupo de serviços de imagem configurados para realizar uma análise por sobreposição extremamente intensiva em 15 conjuntos raster.  Os serviços foram configurados idênticos exceto pelos tipos de pixel e compressão dos dados da análise.  Os testes foram realizados na escala do mapa correspondente ao tamanho do pixel dos dados.<\/P><\/>

        Gráficos 5 &amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;&;amp;;amp;;amp;;amp;;amp;;amp;;amp;;amp;;amp;;amp;;amp;;amp;;amp;;amp;;amp;;amp;;amp;;amp;;amp;;amp;;amp;;amp;;amp;;amp;;amp;;amp;>. Tempo médio de resposta e tamanho do armazenamento vs. tipo de compressão para um serviço de imagem que realiza uma análise complexa por sobreposição<\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/><\/> em diferentes tamanhos de solicitação no serviço de análise de sobreposição ponderada que usei para os testes de reprojeção em tempo real.  Eu medi os tempos médios de resposta para tamanhos de solicitação variando de 400x400 a 2200x2200, aumentando em incrementos de 100 pixels (por exemplo, 500x500, 600x600, etc66).  Todos os testes foram realizados na escala do mapa de 1:113386, que corresponde ao tamanho do pixel de 30 metros dos conjuntos de dados raster fonte.<\/P>

        <\/A>

        Gráfico 9. Resposta média em MP\/s para diferentes tamanhos de solicitação para o serviço de sobreposição ponderada.<\/P><\/DIV>

        <\/A>

        Gráfico 10. Tempo médio de resposta em diferentes tamanhos de solicitação para o serviço de sobreposição ponderada.<\/P><\/DIV>

        <\/P>

        <\/P>

        O Gráfico 9 mostra que a taxa de transferência para este serviço se estabiliza em um tamanho de solicitação de aproximadamente 1000x1000 pixels em cerca de 1,5 61,6 MP\/s.  O Gráfico 10 mostra que o tamanho da solicitação tem um impacto linear no desempenho.  Este serviço é capaz de fornecer tempos de resposta inferiores a um segundo para solicitações de até cerca de 1.440.000 pixels, ou um tamanho de solicitação de 1200x1200.<\/P>

        <\/P>

        Resumo<\/STRONG><\/P><\/P>A análise raster pode envolver muitas etapas de processamento e análise de dados.  Cadeias complexas de processamento em tempo real podem impor cargas pesadas no servidor e contribuir para um desempenho lento.  Melhorias enormes no desempenho podem ser alcançadas em alguns casos pré-processando os dados em um formato mais eficiente para reamostragem e processamento em tempo real.<\/P><\/P>Para aplicações que usam camadas base em mosaico, as maiores melhorias no desempenho provavelmente serão alcançadas alinhando os tamanhos dos pixels dos dados com as escalas do esquema de mosaico da camada base.  A seção 2Map Scales and Source Data Resolution2 descreve a teoria por trás dessa abordagem e fornece uma tabela com tamanhos recomendados de pixel para aplicações que usam camadas base com o esquema de mosaico ArcGIS Online\Bing Maps\Google Maps.  Alternativamente, os desenvolvedores podem construir camadas base com esquemas personalizados para alinhar com os tamanhos existentes dos pixels dos dados da análise.<\/P><\/P>Outra forma de reduzir significativamente a carga de processamento no servidor em alguns casos é evitar a projeo em tempo real dos dados da análise.  Isso é realizado garantindo que a camada base e os dados da análise estejam no mesmo sistema de coordenadas.  O impacto no desempenho da projeo em tempo real varia dependendo dos sistemas de coordenadas de entrada e saída e é discutido na seção intitulada 2On-the-fly Projection2.<\/P><\/P>O formato do arquivo, tipo do pixel e tipo da compressão dos dados da análise também podem ter um grande impacto no desempenho.  GeoTIFF com blocos internos é recomendado para situações onde é necessário reformatar os dados a partir de um formato mais lento.  Tipos de pixel com menor precisão oferecem melhor desempenho do que tipos com maior precisão.  A compressão do pixel tem potencial para aumentar ou diminuir o desempenho dependendo da forma como os dados são armazenados e acessados pelo servidor.  Esses tópicos são discutidos nas seções intituladas 2Raster Format2 e 2Pixel Type and Compression2.<\/P><\/P>Aplicações cliente também podem desempenhar um papel no desempenho dinâmico do serviço de imagem.  Os tempos de resposta do serviço são menores quando as aplicações especificam reamostragem por vizinho mais próximo, seguida pela reamostragem bilinear.  E há uma relação direta entre o desempenho do serviço e o tamanho da janela do mapa em uma aplicação.  Esses tópicos são discutidos nas seções intituladas 2Resampling Method2 e 2Request Size2.<\/P><\/BODY><\/HTML>

DavidJohnson5

I think you have the right idea.  It's great that you are getting good performance at 1:10,000, even though one of the pyramid levels in your source data corresponds to a map scale of 1:10,500. That's the power of Image Server at work!  Image Server is highly optimized out-of-the-box.  For typical service configurations and usages, details like the pixel sizes of the source data are not significant factor in overall performance.  However based on my results, I expect you would get even better performance if the pyramid in your data was at 9,500 instead of 10,500.  Although it's possible that the improvement may not be easily perceived at the human level in your case.  Putting this in perspective, the service I used to generate my results performed a server-side analysis on 11 different raster datasets. So the performance impact of resampling from 11 datasets with sub-optimal pixel sizes was greatly amplified.  Typical image services do not require this amount of heavy lifting.  But for cases like mine where performance was not satisfactory, this is one approach that can potentially bring huge gains in performance.