Tenho um enigma de que estou recebendo conselhos contraditórios sobre como proceder. Portanto, gostaria de colocá-lo no GIS-SE para obter algumas respostas justificadas.
Cenário:
O cliente possui um aplicativo de mapeamento da web. Não deseja dividir em vários aplicativos menores. Embora isso vá contra o que a abordagem moderna é para mapas na web (por exemplo, muitos aplicativos de mapas da web focados em um mapa da web principal), acredito firmemente que, para alguns usuários, tentar replicar um aplicativo GIS na web é ok ( algumas vezes )
O cliente armazenou em cache o máximo de suas camadas do mapa base em serviços separados.
- O cliente ainda requer 600-700 camadas adicionais em um serviço de mapa dinâmico ...
- O serviço será publicado com todas essas camadas desativadas .
- Não é esperado que os usuários ativem mais de 10 a 40 camadas por vez.
Eu imagino que sua reação inicial a isso é semelhante à minha (600+ ?! WTF ?!)
No entanto - o requisito é definido em pedra e por que não? O aplicativo ArcIMS anterior tinha funcionalidade semelhante; então, por que esse produto ArcGIS Server mais recente não pode fazer o mesmo? Os usuários potencialmente precisam ser capazes de comparar e executar análises em toda a gama de camadas, mesmo que elas pertençam a outros departamentos.
Antes de tirar conclusões precipitadas, o cliente é um administrador do ArcGIS Server.
Eles administraram as 600 camadas de acordo com todas as regras de melhores práticas: por exemplo, intervalos de escala combinados com consultas de definição; anotação sobre rotulagem; generalização de camadas complexas em pequenas escalas; publicar como MSDs; etc
Problema :
Qual é a melhor abordagem aqui?
Publique todas as 600 camadas em um serviço de mapa dinâmico
Divida as camadas em agrupamentos lógicos (hidrologia, planejamento, ecologia, utilidades, etc.)
Se você for com o número 1 e tiver algumas camadas complexas ativadas. Se você deseja ativar uma camada simples de pontos, o ArcGIS Server ainda terá que renderizar as camadas inteiras novamente.
Se você optar pelo nº 2, sempre que fizer uma solicitação, o aplicativo da Web poderá ter que fazer vários pedidos GET para ExportMaps a partir dos serviços de mapas individuais (isso é ruim ou cria carga adicional para o ArcGIS Server sobre o nº 1 ?)
E isso leva à configuração e ajuste para garantir que tudo seja o mais rápido possível. Podemos escalar o back-end do ArcGIS Server para vários hosts e ter um bom hardware para acomodá-lo.
Se você optar pelo número 1, poderá lançar o número máximo de instâncias que o AGS pode manipular.
Se você for o número 2, presumo que você avalie o desempenho dos serviços de mapa (teste de carga e verifique os tempos de espera) e resolva as instâncias mín. / Máx. De acordo para garantir que não haja um serviço que seja um 'link fraco'.
Atualmente, estou me inclinando para a abordagem nº 2, pois minha cabeça ainda está me dizendo que ter 600 camadas em um serviço é loucura, mas se todas estiverem desativadas por padrão, realmente não haverá problema.
Gostaria de ouvir seus pensamentos. Informe-me se precisar de mais informações através dos comentários, mas sem procurar respostas como "usar um aplicativo de desktop" ou "educá-los para fazer as coisas de maneira diferente"
Das discussões nos comentários, deixei de mencionar outra consideração. O aplicativo em que o serviço será consumido possui a capacidade de segurança no nível da camada (no nível do aplicativo). Portanto, o grupo de usuários (que é bastante grande) é atribuído a uma função específica, e essa função terá acesso às 600 camadas completas. Outras funções serão limitadas.
fonte
Respostas:
Utilizou a Ferramenta de Planejamento da Capacidade para ajudar a comparar um serviço de mapa super pesado versus serviços de mapa 4 lite, e os resultados indicam que o serviço de mapa pesado é o caminho a percorrer.
Esta pode não ser a resposta certa, e a ferramenta de planejamento de capacidade não leva em consideração todos os fatores (por exemplo, fluxos de trabalho do usuário) - deixe-me saber por comentários o que você pensa.
1 serviço de mapa super pesado:
utilização da CPU do servidor de aplicativos = 49,4%
Utilização da CPU do servidor de banco de dados = 7,6%
Carga da rede = 16 Mbps
Tempo de resposta da tela = 0,88 segundos
(As imagens podem ser vistas em grande escala por RC e abrir em uma nova guia)
4 serviços de mapa virtual:
utilização da CPU do servidor de aplicativos = 55,4%
utilização da CPU do servidor de banco de dados = 7,6%
carga de rede = 64 Mbps
Tempo de resposta da tela = 0,32 segundos cada, portanto, entre 0,32 e 1,28 segundos, dependendo das despesas gerais do navegador da web
Mais lógica para suportar a abordagem de serviço de um mapa:
Todas as camadas estão no mesmo serviço de mapa;
uma. uma solicitação é enviada ao servidor
b. um processo SOC desenha o mapa
c. uma imagem é retornada pela rede
As 40 camadas estão espalhadas por 4 serviços de mapas (10 camadas cada), portanto;
uma. 4 solicitações são enviadas ao servidor
b. 4 processos SOC desenham um mapa
c. 4 imagens são retornadas pela rede
1a e 1c serão mais rápidos e colocarão menos carga na rede do que 2a e 2c.
2b pode usar o processamento paralelo para retornar um mapa mais rápido que 1b para um único usuário, mas esse não será o caso para muitos usuários. De fato, a sobrecarga das transações adicionais sendo processadas pelo servidor em 2b (mais a carga de rede adicional de 2c) verá a escala 1b muito melhor à medida que o número de usuários aumenta.
fonte
Embora o uso de vários serviços, o dimensionamento de camadas / etiquetas, o armazenamento em cache e o uso de etiquetas não dinâmicas ajudem a melhorar a experiência do aplicativo Web, o impacto inicial para carregar todas as mais de 600 camadas em um aplicativo será perceptível pelo usuário final. Especialmente o tempo necessário para preencher o sumário. Se você tiver que criar um aplicativo com mais de 600 camadas, eu definitivamente optaria pela opção nº 2. Você pode modelar sua estrutura de dados com base em um modelo de dados (como o modelo de dados do governo local).
O whitepaper abaixo destaca algumas diretrizes interessantes de boas práticas e estatísticas de desempenho para configurações de aplicativos da web do ArcGIS Server.
http://www.esri.com/library/whitepapers/pdfs/creating-arcgisserver-web-mapping.pdf
fonte