Beaucoup de couches dans un ou plusieurs services? (et pourquoi)


13

J'ai une énigme que je reçois des conseils mitigés sur la façon de procéder. C'est pourquoi j'aimerais le mettre au GIS-SE pour des réponses justifiées.

Scénario:

  • Le client dispose d'une application de cartographie Web. Ne souhaite pas se diviser en plusieurs applications plus petites. Bien que cela va à l'encontre de l'approche moderne des cartes sur le Web (c.-à-d. De nombreuses applications de cartes Web ciblées sur une carte Web principale), je crois fermement que pour certains utilisateurs, essayer de répliquer une application SIG sur le Web est ok ( parfois ).

  • Le client a mis en cache autant de ses couches de fond de carte dans des services distincts.

  • Le client a encore besoin de 600 à 700 couches supplémentaires dans un service de carte dynamique ...
  • Le service sera publié avec toutes ces couches désactivées .
  • Il n'est pas prévu que les utilisateurs activent plus de 10 à 40 couches à la fois.

J'imagine que votre réaction initiale à cela est similaire à la mienne (600+?! WTF ?!)

Cependant - l'exigence est gravée dans le marbre et pourquoi pas? Leur précédente application ArcIMS avait des fonctionnalités similaires, alors pourquoi ce nouveau produit ArcGIS Server ne peut-il pas faire de même? Les utilisateurs doivent potentiellement pouvoir comparer et effectuer des analyses sur toute la gamme de couches, même si les couches appartiennent à d'autres services.

Avant de tirer des conclusions, le client est un administrateur ArcGIS Server informé.
Ils ont administré les 600 couches selon toutes les règles de bonnes pratiques: par exemple, les plages d'échelle combinées aux requêtes de définition; annotation sur l'étiquetage; généraliser des couches complexes à petite échelle; publier en tant que TMS; etc

Problème :

Quelle est la meilleure approche ici?

  1. Publiez les 600 couches dans un service de carte dynamique

  2. Divisez les couches en groupes logiques (hydrologie, planification, écologie, services publics, etc.)

Si vous optez pour # 1 et que vous avez activé quelques calques complexes. Si vous souhaitez activer une couche de points simples, ArcGIS Server devra tout de même restituer l'intégralité des couches.

Si vous optez pour le n ° 2, chaque fois que vous effectuez une demande, l'application Web pourrait devoir effectuer plusieurs demandes GET pour ExportMaps à partir des services de carte individuels (est-ce mauvais ou crée-t-il une charge supplémentaire sur ArcGIS Server sur le n ° 1) ?)

Et cela conduit à la configuration et au réglage pour s'assurer que tout est aussi rapide que possible. Nous pouvons faire évoluer le back-end d'ArcGIS Server sur plusieurs hôtes et disposer d'un bon matériel pour s'y installer.

Si vous optez pour le n ° 1, vous pouvez lancer le nombre maximal d'instances que AGS peut gérer.

Si vous optez pour le # 2, je suppose que vous évaluez les performances des services de carte (test de charge et examinez les temps d'attente) et adressez les instances min / max en conséquence pour vous assurer qu'il n'y a pas un service qui soit un `` maillon faible ''.

Je penche actuellement vers l'approche # 2, car ma tête me dit toujours qu'avoir 600 couches dans un service est une folie, mais si elles sont toutes désactivées par défaut, il n'y a vraiment pas de problème.

Aimerais entendre vos pensées. Faites-moi savoir si vous avez besoin de plus d'informations via les commentaires, mais ne cherchez pas de réponses comme «utiliser une application de bureau» ou «les éduquer à faire les choses différemment»


Des discussions dans les commentaires, je n'ai pas mentionné une autre considération. L'application dans laquelle le service sera consommé a la capacité de sécurité au niveau de la couche (au niveau de l'application). Par conséquent, le groupe d'utilisateurs (qui est assez important) est affecté à un rôle particulier, et ce rôle aura accès aux 600 couches complètes. D'autres rôles seront limités.


Personnellement, je poserais une question au PM décrivant le problème, conseillerais sur les meilleures pratiques, conseillerais une issue, puis la laisserais entre leurs mains. À la fin de la journée, dès que quelqu'un vous dit: «mais c'est comme ça», vous avez les mains pleines. Dans cette situation, je ferais comme ci-dessus, alors vous avez été professionnel, vous avez fait votre travail et le reste est à eux. Je conseillerais également d'inclure toute personne riche et célèbre en ce qui concerne votre lieu de travail, dans le courrier électronique, pour vous assurer que le conseil est là-bas et que tout le monde sait quel était le conseil et qui l'a donné.
Hairy

Vous ne dites pas le type d'application Web qui sera utilisé pour parcourir les couches, mais je suppose qu'il s'agit d'une sorte de couches ouvertes. Dans ce cas, gardez à l'esprit que le navigateur peut également présenter des problèmes, car il n'émettra pas plus de quelques (entre 2 et 6) demandes simultanées au même serveur (y compris XHR, css et tout). Voir cet article pour les détails et quelques alternatives (je préfère généralement les cnames multiples lorsque l'informatique est coopérative): stevesouders.com/blog/2008/03/20/…
unicoletti

@Hairy - Je pense en fait que nous pouvons répondre aux exigences du client avec ArcGIS Server, et bien qu'il repousse les limites de ce qui est possible avec AGS, c'est toujours faisable, et nous pouvons toujours nous rabattre sur nos conseils antérieurs pour briser le application dans plusieurs applications.
Simon

1
Je sais que c'est faisable, j'ai travaillé avec des clients qui font de même, mais je ne pense pas que ce soit recommandé, ce sont des choses différentes. S'ils décident d'avoir 10 clients qui veulent les 600 couches en même temps, peu importe sur quoi vous exécutez AGS, cela tombera
Hairy

Réponses:


8

Nous avons utilisé l' outil de planification de la capacité pour comparer un service de carte super lourd et 4 services de carte allégés, et les résultats indiquent que le service de carte lourd est la solution.

Ce n'est peut-être pas la bonne réponse, et l'outil de planification des capacités ne prend pas en compte tous les facteurs (par exemple, les flux de travail des utilisateurs) - faites-moi savoir par commentaires ce que vous en pensez.

1 service de carte super lourd:
utilisation du processeur du serveur d'applications = 49,4%
utilisation du processeur du serveur de bases de données = 7,6%
charge réseau = 16 Mbps
temps de réponse d'affichage = 0,88 s

(Les images peuvent être vues en grand par RC et ouvertes dans un nouvel onglet)

entrez la description de l'image ici

4 services de carte allégée:
utilisation du processeur du serveur d'applications = 55,4%
utilisation du processeur du serveur de bases de données = 7,6%
charge réseau = 64 Mbps
temps de réponse d'affichage = 0,32 seconde chacun, donc entre 0,32 et 1,28 seconde en fonction des frais généraux du navigateur Web

entrez la description de l'image ici

Plus de logique pour prendre en charge l'approche du service de carte unique:

  1. Toutes les couches sont donc dans le même service de carte;
    une. une demande est envoyée au serveur
    b. un processus SOC dessine la carte
    c. une image est renvoyée sur le réseau

  2. Les 40 couches sont donc réparties sur 4 services de carte (10 couches chacun);
    une. 4 demandes sont envoyées au serveur
    b. 4 Les processus SOC dessinent une carte
    c. 4 images sont retournées sur le réseau

1a et 1c seront plus rapides et mettront moins de charge sur le réseau que 2a et 2c.

2b peut utiliser le traitement parallèle pour renvoyer une carte plus rapidement que 1b pour un seul utilisateur, mais ce ne sera pas le cas pour de nombreux utilisateurs. En fait, les frais généraux des transactions supplémentaires traitées par le serveur en 2b (plus la charge réseau supplémentaire de 2c) verront l'échelle 1b beaucoup mieux à mesure que le nombre d'utilisateurs augmentera.


2
cela semble logique. La gestion du MXD 600 couches ne semble pas très amusante.
Stephen Lead

1

Bien que l'utilisation de plusieurs services, la mise à l'échelle des couches / étiquettes, la mise en cache et l'utilisation d'étiquettes non dynamiques contribuent à améliorer l'expérience de l'application Web, le résultat initial pour charger les 600+ couches dans une seule application sera perceptible par l'utilisateur final. Surtout le temps qu'il faut pour remplir la table des matières. Si vous devez créer une application de plus de 600 couches, j'irais certainement avec l'option # 2. Vous souhaiterez peut-être modéliser votre structure de données par rapport à un modèle de données (tel que le modèle de données du gouvernement local).

Le livre blanc ci-dessous présente quelques recommandations de bonnes pratiques et statistiques de performances intéressantes pour les configurations d'applications Web ArcGIS Server.

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


Bon point sur le TOC, mais il se charge en fait très bien. 'hit initial pour charger 600+ couches' = du point de vue de la demande de carte, il ne fait toujours qu'une seule demande pour un seul service. Il est donc assez rapide pour AGS de retourner l'exportation JUSQU'À ce qu'ils commencent à activer> 20 couches.
Simon
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.