escritório GIS em uma caixa<\/A>, por exemplo. Como qualquer escritório, o equilíbrio entre o número de funcionários vs. demanda vs. recursos é um cálculo contínuo. E isso é verdade também no nosso escritório ArcGIS em uma caixa. A maioria dos escritórios GIS tem capacidade limitada de pessoal por fatores como estações de trabalho disponíveis, largura de banda da rede ou licenças de software essencial. Se ficarmos sem mesas e computadores que os analistas possam usar, não podemos adicionar mais analistas ao escritório. Se todos os analistas estiverem trabalhando em algumas tarefas, não podemos pedir para iniciar uma nova tarefa. Mesmo que ampliemos o espaço e adicionemos infraestrutura, não podemos usar essa capacidade aumentada se não comprarmos mais licenças do ArcGIS Pro. Com o ArcGIS Server podemos enfrentar os mesmos desafios e limites. Portanto, é vital configurar os serviços web GIS (services) executados no ArcGIS Server para usar eficientemente os recursos finitos disponíveis, garantindo também o melhor rendimento e velocidade para o sistema.<\/P> <\/P>
Cada serviço não hospedado no ArcGIS Server tem um conjunto de opções de configuração que podem ser definidas no momento da publicação no ArcGIS Pro ou após a publicação com a aplicação administrativa web ArcGIS Server Manager. Um serviço pode existir no ArcGIS Server em muitos estados. Primeiro ele é publicado. Isso significa que um arquivo de definição do serviço foi criado, e ele existe dentro do diretório Server em uma subpasta chamada arcgisinput, por padrão encontrada em C:\arcgisserver\directories\arcgissystem\arcgisinput. Segundo, o serviço pode estar em execução ou parado. Por padrão, serviços publicados são iniciados quando publicados, embora serviços possam ser parados também. Quando um serviço está iniciado e em execução ele é "anunciado" em outra aplicação web chamada ArcGIS Server Services Directory. Aqui administradores, publicadores e desenvolvedores encontram propriedades úteis e operações suportadas que podem ser usadas para inspecionar e usar os serviços.<\/P>
<\/P>
Outro resultado de iniciar um serviço no ArcGIS Server é que os componentes gerenciadores do nosso "escritório" iniciarão o número mínimo de instâncias definido para o serviço, por padrão isso é uma instância. Tecnicamente uma instância de um serviço é uma única unidade de processamento, tipicamente manifestada como um processo ArcSOC.exe rodando no sistema operacional do computador host. Você pode pensar em uma instância de um serviço como um analista sentado em uma mesa com o projeto necessário do ArcGIS Pro disponível para ele que pode responder a solicitações para capacidades definidas do recurso GIS anunciado. Note que o número de instâncias em execução não está diretamente relacionado ao número de aplicações nem pessoas "usando" o serviço. Neste caso a instância está rodando e apenas esperando por uma solicitação. Isso é chamado estado ocioso da instância.<\/P>
<\/P>
ArcGIS Server Manager e Gerenciador de Tarefas do Windows mostrando instâncias de um serviço web GIS.<\/span><\/span><\/P> <\/P>O número mínimo de instâncias define quantas instâncias do serviço são iniciadas quando o serviço é iniciado. Isso pode ser definido para qualquer número incluindo zero. Mas não exagere nesse número, lembre-se que o servidor GIS tem recursos finitos disponíveis e provavelmente há outros serviços rodando que precisam usar esses recursos para suportar suas próprias instâncias também. Mas isso é só o mínimo. Também há um número máximo de instâncias que podem ser criadas. Esse máximo pode ser maior ou igual ao número mínimo de instâncias. Por padrão, esse número é dois. Então, por padrão quando um serviço é publicado no ArcGIS Server o maior número de analistas virtuais que podem existir para responder às solicitações desse serviço é dois. Será que isso será suficiente? Muito provavelmente não. Especialmente se este for um serviço com demanda média a alta. Mas novamente, lembre-se que embora você possa definir esse máximo para qualquer número, você pode facilmente sobrecarregar seu sistema permitindo mais instâncias serem criadas do que o sistema total consegue suportar. Além disso, haverá outros serviços rodando no ArcGIS Server com suas próprias instâncias que também precisam consumir esses recursos finitos.<\/P> <\/P>
ArcGIS Server Manager com configurações de configuração das instâncias.<\/span><\/span><\/P> <\/P>Até o ArcGIS 10.7, essa era a única forma de controlar o número de analistas (instâncias) que existiam no nosso escritório GIS (ArcGIS Server). Todas as instâncias existentes no ArcGIS Server eram definidas separadamente para cada serviço e só podiam responder às solicitações daquele serviço específico. Podemos pensar nisso como se cada analista no nosso escritório GIS só pudesse abrir um projeto por vez no ArcGIS Pro e o projeto só pudesse ter um mapa, ou cena, ou modelo, ou outro recurso GIS único com o qual o analista pudesse interagir para responder às solicitações. Essas são chamadas instâncias dedicadas.<\/P> <\/P>Então no ArcGIS 10.7, introduzimos um novo conceito chamado pool compartilhado de instâncias (shared instance pool). As instâncias nesse pool podem responder às solicitações para qualquer serviço atribuído a ele, com certos limites sobre quais tipos de serviços podem ser atribuídos ao pool. Você pode considerar esse pool compartilhado como alguns analistas no nosso escritório que têm uma cópia do mesmo projeto aberto no ArcGIS Pro que tem muitos mapas (um para cada serviço atribuído ao pool) disponíveis nele. O benefício disso é que os serviços com baixa demanda já têm instâncias rodando para suportá-los rapidamente, mas os recursos do computador não estão sendo desperdiçados em instâncias que não estão em uso.<\/P> <\/P>Uma última consideração ao falar sobre as instâncias de um serviço é que nem todos os serviços aos quais nossos usuários têm acesso são gerenciados como serviços separados no ArcGIS Server. Por exemplo, quando você publica um map service há um map service disponível no Server Manager para gerenciar propriedades como o número mínimo/máximo de instâncias. Esse map service também tem sua própria URL ou ponto final pelo qual os clientes se comunicam. Mas o objeto map service no ArcGIS Server Manager também tem uma propriedade capabilities (capacidades). Através dessa propriedade capacidades adicionais podem ser habilitadas como a feature access capability (capacidade de acesso a feição). Habilitar isso fará com que o ArcGIS Server crie outra URL para um feature service (serviço de feição). Mas esse feature service e quaisquer outros serviços habilitados via capability não criam suas próprias instâncias. As instâncias originais criadas para o map service associado também suportam o feature service.<\/P> <\/P>
ArcGIS Server Manager mostrando a URL de um map service.<\/span><\/span><\/P> <\/P>
ArcGIS Server Manager mostrando a URL de um feature service.<\/span><\/span><\/P> <\/P>Através deste artigo vimos que existem muitas formas pelas quais podemos controlar e gerenciar serviços web GIS para afetar a performance fornecida pelo ArcGIS Server. Mas o ArcGIS Server é apenas uma parte do processo de criar, gerenciar e compartilhar recursos GIS. Na maioria dos casos as decisões que tomamos ao armazenar os dados GIS ou criar os recursos terão maior impacto do que essas opções aqui apresentadas. No currículo oficial da Esri ministrado por instrutores discutimos e implementamos muitas técnicas específicas de otimização de conteúdo em nosso curso
