Más

¿Muchas capas en uno o varios servicios? (y por qué)

¿Muchas capas en uno o varios servicios? (y por qué)


Tengo un acertijo de que estoy recibiendo consejos contradictorios sobre cómo hacerlo. Por lo tanto, me gustaría ponerlo en GIS-SE para obtener algunas respuestas justificadas.

Guión:

  • El cliente tiene una aplicación de mapas web. No quiere dividirse en múltiples aplicaciones más pequeñas. Aunque esto va en contra de lo que es el enfoque moderno para los mapas en la web (es decir, muchas aplicaciones de mapas web enfocadas en un mapa web principal), creo firmemente que para algunos usuarios, intentar replicar una aplicación GIS en la web es ok (a veces).

  • El cliente ha almacenado en caché la mayor parte de sus capas de mapa base en servicios separados.

  • El cliente aún requiere un adicional 600-700 capas en un dinámica servicio de mapas ...
  • El servicio se publicará con todas estas capas. apagado.
  • No se prevé que los usuarios activen más de 10 a 40 capas a la vez.

Me imagino que tu reacción inicial a esto es similar a la mía (¡¿600+ ?! ¡¿WTF ?!)

Sin embargo, el requisito está escrito en piedra y ¿por qué no? Su aplicación ArcIMS anterior tenía una funcionalidad similar, entonces, ¿por qué este producto ArcGIS Server más nuevo no puede hacer lo mismo? Los usuarios potencialmente necesitan poder comparar y realizar análisis en toda la gama de capas, incluso si las capas pertenecen a otros departamentos.

Antes de sacar conclusiones, el cliente es un administrador de ArcGIS Server informado.
Han administrado las 600 capas según todas las reglas de mejores prácticas: p. Ej. rangos de escala combinados con consultas de definición; anotación sobre etiquetado; generalizar capas complejas a pequeña escala; publicar como MSD; etc

Problema:

¿Cuál es el mejor enfoque aquí?

  1. Publique las 600 capas en un servicio de mapas dinámicos

  2. Divida las capas en agrupaciones lógicas (hidrología, planificación, ecología, servicios públicos, etc.)

Si va con el n. ° 1, y tiene algunas capas complejas activadas. Si desea activar una capa de puntos simple, ArcGIS Server aún tendrá que renderizar todas las capas que se muestran nuevamente.

Si va con el n. ° 2, cada vez que realiza una solicitud, potencialmente, la aplicación web podría tener que realizar varias solicitudes GET para ExportMaps desde los servicios de mapas individuales (¿esto es malo o crea una carga adicional en ArcGIS Server sobre el n. ° 1? ?)

Y luego esto conduce a la configuración y ajuste para garantizar que todo sea lo más rápido posible. Podemos escalar el back-end de ArcGIS Server a varios hosts y tener un buen hardware para colocarlo.

Si elige el número 1, puede lanzar el número máximo de instancias que AGS puede manejar.

Si elige el n. ° 2, supongo que evalúa el rendimiento de los servicios de mapas (prueba de carga y observa los tiempos de espera) y aborda las instancias mínimas / máximas en consecuencia para asegurarse de que no haya un solo servicio que sea un 'vínculo débil'.

Actualmente me inclino hacia el enfoque n. ° 2, ya que mi cabeza todavía me dice que tener 600 capas en un servicio es una locura, pero si todas están desactivadas de forma predeterminada, realmente no hay problema.

Me encantaría conocer tu opinión. Avíseme si necesita más información a través de los comentarios, pero sin buscar respuestas como 'usar una aplicación de escritorio' o 'educarlos para que hagan las cosas de manera diferente'


De las discusiones en los comentarios, no mencioné otra consideración. La aplicación en la que se consumirá el servicio tiene la capacidad de seguridad a nivel de capa (a nivel de aplicación). Por lo tanto, al grupo de usuarios (que es bastante grande) se le asigna un rol en particular, y ese rol tendrá acceso a las 600 capas completas. Otros roles serán limitados.


Se utilizó la herramienta de planificación de capacidad para ayudar a comparar un servicio de mapas súper pesado con 4 servicios de mapas ligeros y los resultados indican que el servicio de mapas pesado es el camino a seguir.

Puede que esta no sea la respuesta correcta, y la herramienta de planificación de capacidad no tiene en cuenta todos los factores (por ejemplo, los flujos de trabajo de los usuarios); hágamelo saber a través de los comentarios lo que piensa.

1 servicio de mapas superpesados:
Utilización de la CPU del servidor de aplicaciones = 49,4%
Utilización de la CPU del servidor de base de datos = 7,6%
Carga de red = 16 Mbps
Tiempo de respuesta de la pantalla = 0,88 segundos

(Las imágenes se pueden ver en grande por RC y abrir en una nueva pestaña)

4 servicios de mapas lite:
Utilización de la CPU del servidor de aplicaciones = 55,4%
Utilización de la CPU del servidor de base de datos = 7,6%
Carga de red = 64 Mbps
Tiempo de respuesta de la pantalla = 0,32 segundos cada uno, por lo que entre 0,32 y 1,28 segundos, según los gastos generales del navegador web

Más lógica para respaldar el enfoque del servicio de un mapa:

  1. Todas las capas están en el mismo servicio de mapas, por lo tanto;
    una. se envía una solicitud al servidor
    B. un proceso de SOC dibuja el mapa
    C. se devuelve una imagen a través de la red

  2. Las 40 capas se distribuyen en 4 servicios de mapas (10 capas cada una), por lo tanto;
    una. Se envían 4 solicitudes al servidor
    B. 4 procesos de SOC dibujan un mapa
    C. Se devuelven 4 imágenes a través de la red

1a y 1c serán más rápidos y pondrán menos carga en la red que 2a y 2c.

2b puede utilizar el procesamiento paralelo para devolver un mapa más rápido que 1b para un solo usuario, pero este no será el caso para muchos usuarios. De hecho, la sobrecarga de las transacciones adicionales que está procesando el servidor en 2b (más la carga de red adicional de 2c) verá una escala de 1b mucho mejor a medida que aumenta el número de usuarios.


Aunque el uso de múltiples servicios, el escalado de capas / etiquetas, el almacenamiento en caché y el uso de etiquetas no dinámicas ayudan a mejorar la experiencia de la aplicación web, el usuario final notará el impacto inicial para cargar las más de 600 capas en una aplicación. Especialmente el tiempo que se tarda en rellenar el TOC. Si tiene que crear una aplicación de más de 600 capas, definitivamente elegiría la opción n. ° 2. Es posible que desee modelar su estructura de datos contra un modelo de datos (como el modelo de datos del gobierno local).

El documento técnico a continuación destaca algunas pautas de mejores prácticas interesantes y estadísticas de rendimiento para las configuraciones de aplicaciones web de ArcGIS Server.

http://www.esri.com/library/whitepapers/pdfs/creating-arcgisserver-web-mapping.pdf