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?
Publiez les 600 couches dans un service de carte dynamique
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.
Réponses:
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)
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
Plus de logique pour prendre en charge l'approche du service de carte unique:
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
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.
la source
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
la source