Ho un enigma nel ricevere consigli contrastanti su come procedere. Quindi mi piacerebbe metterlo al GIS-SE per alcune risposte giustificate.
Scenario:
Il client ha un'applicazione di mappatura web. Non vuole suddividere in più applicazioni più piccole. Sebbene ciò vada contro l'approccio moderno per le mappe sul Web (ovvero molte app per mappe Web focalizzate su una mappa Web principale), credo fermamente che per alcuni utenti, provare a replicare un'applicazione GIS sul Web sia ok (a volte ).
Il client ha memorizzato nella cache la maggior parte dei livelli della sua mappa di base in servizi separati.
- Il client richiede ancora ulteriori 600-700 livelli in un servizio di mappe dinamiche ...
- Il servizio verrà pubblicato con tutti questi livelli disattivati .
- Non è previsto che gli utenti accendano più di 10-40 livelli alla volta.
Immagino che la tua reazione iniziale a questo sia simile alla mia (600+ ?! WTF ?!)
Tuttavia, il requisito è impostato sulla pietra e perché no? La loro precedente applicazione ArcIMS aveva funzionalità simili, quindi perché questo nuovo prodotto ArcGIS Server non può fare lo stesso? Gli utenti devono potenzialmente essere in grado di confrontare ed eseguire analisi incrociate sull'intera gamma di livelli, anche se i livelli appartengono ad altri dipartimenti.
Prima di saltare alle conclusioni, il client è un amministratore ArcGIS Server ben informato.
Hanno amministrato i 600 livelli secondo tutte le regole delle migliori pratiche: ad es. Intervalli di scala combinati con query di definizione; annotazione su etichettatura; generalizzare strati complessi su piccola scala; pubblicare come MSD; eccetera
Problema :
Qual è l'approccio migliore qui?
Pubblica tutti i 600 livelli in un unico servizio di mappa dinamica
Dividi i livelli in raggruppamenti logici (idrologia, pianificazione, ecologia, utilità, ecc.)
Se vai con il n. 1 e hai attivato alcuni livelli complessi. Se si desidera attivare un semplice livello punti, ArcGIS Server dovrà comunque eseguire nuovamente il rendering degli interi livelli.
Se si va con il n. 2, ogni volta che si effettua una richiesta, potenzialmente, l'applicazione Web potrebbe dover effettuare diverse richieste GET per ExportMaps dai singoli servizi di mappe (è un problema o crea un carico aggiuntivo su ArcGIS Server rispetto al n. 1 ?)
E quindi questo porta alla configurazione e alla messa a punto per garantire che tutto sia il più rapido possibile. Possiamo ridimensionare il back-end di ArcGIS Server su più host e disporre di un buon hardware su cui installarlo.
Se vai con il n. 1, puoi lanciare il numero massimo di istanze che puoi gestire con AGS.
Se vai con il n. 2, suppongo che valuti le prestazioni dei servizi della mappa (test di carico e controlli dei tempi di attesa) e indirizzi le istanze min / max di conseguenza per garantire che non vi sia un servizio che sia un "anello debole".
Attualmente mi sto avvicinando all'approccio n. 2, poiché la mia testa mi sta ancora dicendo che avere 600 livelli in un servizio è una follia, ma se sono tutti disattivati per impostazione predefinita, non c'è davvero alcun problema.
Mi piacerebbe sentire i tuoi pensieri. Fammi sapere se hai bisogno di maggiori informazioni tramite i commenti, ma non cerchi risposte come "usa un'applicazione desktop" o "educale a fare le cose in modo diverso"
Dalle discussioni nei commenti, non ho menzionato un'altra considerazione. L'applicazione in cui verrà consumato il servizio ha la capacità di sicurezza a livello di livello (a livello di applicazione). Pertanto, il gruppo di utenti (che è abbastanza grande) è assegnato a un ruolo particolare e quel ruolo avrà accesso a tutti i 600 livelli. Altri ruoli saranno limitati.
