Neste post gostaria de falar um pouco sobre o trabalho que a equipe da GeoSolutions fez recentemente em resposta ao teste preparado pela Camp2Camp para medir e comparar desempenho e escalabilidade dos servidores GeoServer, MapServer e QGIS utilizando 3 mapas do OSM com pontos, linhas e polígonos.

Se você estiver interessado em ver a apresentação (que é em francês), você pode encontrá-la aqui; Se o seu francês é tão ruim quanto o meu, não se preocupe, as imagens importantes sobre o desempenho são auto explicativas:

a. Antes de otimizar o GeoServer

b. Depois de otimizar o GeoServer

Ok, vamos agora um pouco mais a fundo sobre o que é o teste e como você pode replicar esta experiência.

1. O Teste

O sistema é baseado em algumas imagens do docker que contêm os dados, a base de dados e o software. O repositório principal está disponível aqui:

https://github.com/camptocamp/ms_perfs

As imagens do GeoServer podem ser baixadas a partir daqui, assim como as imagens do QGIS e MapServer. Na configuração ele descarrega um mapa preciso dos dados ao redor do mundo e roda o benchmark usando gatling, através de alguns scripts shell, uma classe de teste escrito em Scala, e um script python que realiza a sumarização no final.

A instalação requer o download de todos os dados do OSM, download e compilação de vários pacotes, ou seja, podem ser necessárias várias horas para isso (dependendo de quão rápido seja sua conexão).

Uma execução de teste usa 3 camadas, cada uma com dois estilos diferentes:

  • roads-simple (linha contínua)
  • roads-dashed (linha tracejada)
  • points-simple (circulo)
  • points-class (3 arquivos svg para diferentes tipos de localização)
  • buildings-simple (polígono sólido)
  • buildings-dashed (polígono tracejado)

Cada execução funciona em locais aleatórios em 8 níveis de zoom diferentes, testando cada um separadamente e executando para 1, 2, 5, 10, 20, 40 usuários, portanto, 48 execuções, cada uma trabalhando por 120 segundos.

Cada execução usa todas as camadas em conjunto, mesmo se os relatórios finais forem em horários separados camada por camada (assim, 288 resultados no total).

Uma execução de teste funciona por 1,5 horas por servidor testado, portanto 4,5 horas no total. Os mapas no nível zoom 7 contêm muito poucos itens, e para a camada de pontos são por vezes vazios, no nível de zoom 0, em vez disso, torna-se uma “nuvem de pontos”. Veja:

c. Nivel de zoom 7:

d. Nível de zoom 0:

2. O Resultado

A configuração inicial do GeoServer tinha alguns inconvenientes que foram identificados para melhorar:

a. Utilizava as conexões máximas (10) no pool em relação ao postgresql, o que estava impedindo a escalabilidade com solicitações WMS, portanto, foi elevada. Se você estiver interessado pode encontrar algum material útil sobre isso, você pode acessar aqui, aqui e aqui.

b. Os estilos não eram exatamente iguais entre os vários servidores.

c. Os SVGs foram importados do QGIS tal como estavam, e ainda continham expressões paramétricas para cores, espessuras e opacidades, causando algumas exceções no início da execução.

d. O rasterizador não foi configurado para ser Marlin. Mais informações sobre o tema aqui e aqui.

e. A simplificação da geometria do lado do servidor que estava usando ST_Simplify, que foi desativada, já que a maioria das geometrias eram muito pequenas. Isso pode ser feito desmarcando a caixa de seleção “Suporte na simplificação da geometria da mosca” no final da configuração do Datastore (veja Imagem abaixo).

Como de costume quando se faz este tipo de experiência geralmente encontra-se uma boa maneira de otimizar o GeoServer. Neste caso, foram realizadas algumas melhoras na versão Master do GeoServer, veja:

f. Envio com renderizador Marlin: Devemos enviar o Marlin Renderer entre os jars do GeoServer por padrão, ativar seu uso nos instaladores bin / win / osx, quando o JDK for menos que 1.9.

g. Otimizar a transferência de dados do PostgreSQL: Atualmente nós transferimos dados utilizando o formato WKB, no entanto desde o PostGIS 2.2 temos disponível o TWKB que parece reduzir significativamente a carga útil transferida.

O ST_RemoveRepeatedPoints parece ser também bastante interessante, com pouca sobrecarga, podemos usar por padrão a partir da versão 2.2. do postgis e ter uma flag separada para o uso do ST_Simplify (que é mais pesado). O segundo deve ser ativado na base de dados, talvez considerando também intervalos de escala.

h. Representação dos polígonos: Polígonos em java2d parece ser ainda significativamente mais lento do que no MapServer, isso é algo que é necessário tentar melhorar no nível da JDK.

Fonte: GeoSolutions Blog