¿Muchos niveles en uno o varios servicios? (y por qué)

Question

Tengo un enigma sobre el que estoy recibiendo consejos contradictorios sobre cómo proceder. Por lo tanto, me gustaría plantearlo a GIS-SE para obtener algunas respuestas justificadas.

Escenario:

• El cliente tiene una aplicación de cartografía web. No quiere dividirla en varias aplicaciones más pequeñas. Aunque esto va en contra del enfoque actual de los mapas en la web (es decir, muchas aplicaciones de mapas web centradas en un mapa web principal), creo firmemente que para algunos usuarios, intentar replicar una aplicación SIG en la web está bien ( a veces ).

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

• El cliente sigue necesitando un 600-700 capas en un dinámico servicio de mapas...

• El servicio se publicará con todas estas capas apagado .

• No se prevé que los usuarios enciendan más de 10-40 capas a la vez.

Imagino que tu reacción inicial a esto es similar a la mía (¡¿más de 600?! ¡¿WTF?!)

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

Antes de sacar conclusiones precipitadas, el cliente es un administrador de ArcGIS Server con experiencia.
Han administrado las 600 capas siguiendo todas las normas de buenas prácticas: por ejemplo, rangos de escala combinados con consultas de definición; anotación sobre etiquetado; generalización de capas complejas a pequeña escala; publicación como MSD; etc.

Problema :

¿Cuál es el mejor enfoque en este caso?

1. Publicar las 600 capas en un servicio de mapas dinámico

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

Si eliges el número 1, y tienes unas cuantas capas complejas activadas. Si desea activar una capa de puntos simples, entonces ArcGIS Server tendrá que volver a renderizar todas las capas que se muestran.

Si se opta por el número 2, cada vez que se haga una solicitud, la aplicación web podría tener que hacer varias solicitudes GET para ExportMaps desde los servicios de mapas individuales (¿es esto malo, o crea una carga adicional para ArcGIS Server con respecto al número 1?)

Y luego esto lleva a la configuración y puesta a punto para garantizar que todo sea lo más rápido posible. Podemos escalar el back-end de ArcGIS Server a múltiples hosts y tener un buen hardware para asentarlo.

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

Si se opta por el número 2, supongo que se evaluará el rendimiento de los servicios de mapas (pruebas de carga y observación de los tiempos de espera) y se abordarán las instancias mínimas/máximas en consecuencia para garantizar que no haya un servicio que sea un "eslabón débil".

Actualmente me inclino por el enfoque #2, ya que mi cabeza sigue diciéndome que tener 600 capas en un servicio es una locura, pero si todas están desactivadas por defecto, realmente no hay problema.

Me encantaría conocer su opinión. Hazme saber si necesitas más información a través de los comentarios, pero no busco respuestas como "usa una aplicación de escritorio" o "edúcalos para que hagan las cosas de forma diferente".

---

De las discusiones en los comentarios, me faltó mencionar otra consideración. La aplicación dentro de la cual se consumirá el servicio, tiene la capacidad de seguridad a nivel de capa (a nivel de aplicación). Por lo tanto, el grupo de usuarios (que es bastante grande) se asigna a un rol particular, y ese rol tendrá acceso a las 600 capas completas. Los demás roles estarán limitados.

Answer 1

Utilizó el Herramienta de planificación de la capacidad para ayudar a comparar un servicio de mapas súper pesados frente a 4 servicios de mapas ligeros, y los resultados indican que el servicio de mapas pesados es el mejor.

Puede que esta no sea la respuesta correcta, y que la herramienta de planificación de la capacidad no tenga en cuenta todos los factores (por ejemplo, los flujos de trabajo de los usuarios).

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

(Las imágenes pueden verse en grande por RC y abrirse 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 la base de datos = 7,6%.
Carga de la red = 64 Mbps
Tiempo de respuesta de la pantalla = 0,32 segundos cada uno, es decir, entre 0,32 y 1,28 segundos dependiendo de los gastos generales del navegador web

Más lógica para apoyar el enfoque de un servicio de mapas:

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

2. Por lo tanto, las 40 capas están repartidas en 4 servicios de mapas (10 capas cada uno);
   a. Se envían 4 peticiones al servidor
   b. 4 Procesos SOC dibujar un mapa
   c. Se devuelven 4 imágenes a través de la red

1a y 1c serán más rápidas y cargarán menos 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 esto no será el caso para muchos usuarios. De hecho, la sobrecarga de las transacciones adicionales que procesa el servidor en 2b (más la carga de red adicional de 2c) hará que 1b escale mucho mejor a medida que aumenta el número de usuarios.

Answer 2

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 golpe inicial para cargar las más de 600 capas en una aplicación será perceptible para el usuario final. Especialmente el tiempo que se tarda en rellenar la TOC. Si usted tiene que crear una aplicación de más de 600 capas, yo definitivamente iría con la opción # 2. Es posible que desee modelar su estructura de datos contra un modelo de datos (como el modelo de datos de la administración local).

El siguiente documento técnico destaca algunas pautas de buenas prácticas y estadísticas de rendimiento interesantes para las configuraciones de aplicaciones web de ArcGIS Server.

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