Bir veya birden fazla hizmette çok sayıda katman var mı? (ve neden)

Nasıl devam edeceğim konusunda karışık tavsiyeler aldığım bir muamma var. Bu yüzden bazı haklı cevaplar için CBS-SE koymak istiyorum.

Senaryo:

• İstemcinin bir web harita uygulaması var. Birden fazla küçük uygulamaya bölünmek istemez. Bu, web'deki haritalar için modern yaklaşımın ne olduğuna aykırı olsa da (örneğin, bir ana web haritası üzerinde birçok odaklanmış web haritası uygulaması) Bazı kullanıcılar için, web üzerindeki bir CBS uygulamasını çoğaltmaya çalışanların tamam ( bazen ).

• Müşteri, temel harita katmanlarının çoğunu ayrı hizmetlere önbelleğe aldı.

• Müşteri hala ek bir gerektirir 600-700 katmanları bir de dinamik harita hizmetinde ...
• Hizmet, bu katmanların tümü kapalı olarak yayınlanacak .
• Kullanıcıların bir seferde 10-40'tan fazla katman açması beklenmemektedir.

Buna ilk tepkinizin benimkine benzer olduğunu hayal ediyorum (600+ ?! WTF ?!)

Ancak - gereksinim taşa ayarlanır ve neden olmasın? Önceki ArcIMS uygulamalarının benzer işlevleri vardı, bu yüzden bu yeni ArcGIS Server ürünü neden aynı şeyi yapamıyor? Katmanlar diğer departmanlara ait olsa bile, kullanıcıların potansiyel olarak tüm katman aralığı üzerinde çapraz karşılaştırma ve analiz yapabilmesi gerekir.

Sonuçlara geçmeden önce, istemci bir ArcGIS Server yöneticisidir.
600 katmanı en iyi uygulama kurallarının tümüne göre uygulamışlardır: örneğin, tanım sorgularıyla birlikte ölçek aralıkları; etiketleme üzerine ek açıklama; karmaşık katmanları küçük ölçeklerde genelleme; MSD olarak yayınlamak; vb

Sorun :

Burada daha iyi olan yaklaşım nedir?

1. 600 katmanın tümünü tek bir dinamik harita hizmetinde yayınlayın

2. Katmanları mantıksal gruplara ayırın (hidroloji, planlama, ekoloji, yardımcı programlar, vb.)

# 1 ile devam ederseniz ve açık birkaç karmaşık katmanınız varsa. Basit bir noktalar katmanını açmak istiyorsanız, ArcGIS Server'ın tüm katmanları yeniden görüntülemeye devam etmesi gerekir.

# 2 ile devam ederseniz, her istekte bulunduğunuzda, potansiyel olarak, web uygulamasının tek tek harita hizmetlerinden ExportMaps için birkaç GET isteği yapması gerekebilir (bu kötüdür veya 1'in üzerinde ArcGIS Sunucusuna ek yük oluşturur mu? ?)

Ve sonra bu, her şeyin mümkün olduğunca hızlı olmasını sağlamak için yapılandırma ve ayarlamaya yol açar. ArcGIS Server'ın arka ucunu birden çok ana bilgisayara ölçeklendirebilir ve oturmak için iyi bir donanıma sahip olabiliriz.

# 1 ile giderseniz, AGS'nin işleyebileceği maksimum örnek sayısını atayabilirsiniz.

# 2 ile giderseniz, harita hizmetlerinin performansını değerlendirdiğinizi (yük testi ve bekleme sürelerine bakın) ve 'zayıf bağlantı' olan bir hizmet olmadığından emin olmak için min / maks örneklerini buna göre ele aldığınızı varsayalım.

Şu anda # 2 yaklaşımına yaslanıyorum, çünkü kafam hala bir hizmette 600 katmana sahip olmanın delilik olduğunu söylüyor, ancak hepsi varsayılan olarak kapalı ise, gerçekten sorun yok.

Düşüncelerinizi duymak isterim. Yorumlar aracılığıyla daha fazla bilgiye ihtiyacınız varsa, ancak 'bir masaüstü uygulaması kullanın' veya 'bunları farklı şeyler yapmak için eğitin' gibi yanıtlar aramıyorsanız bana bildirin

Yorumlardaki tartışmalardan, başka bir düşünceden bahsetmedim. Hizmetin içinde kullanılacağı uygulama, katman düzeyinde güvenlik (uygulama düzeyinde) özelliğine sahiptir. Bu nedenle (oldukça büyük olan) kullanıcı grubu belirli bir role atanır ve bu rol 600 katmanın tümüne erişebilir. Diğer roller sınırlı olacaktır.

Bir süper ağır harita hizmetiyle 4 lite harita hizmetlerini karşılaştırmak için Kapasite Planlama Aracı'nı kullandı ve sonuçlar ağır harita hizmetinin yol olduğunu gösteriyor.

Bu doğru cevap olmayabilir ve kapasite planlama aracı her faktörü (örneğin kullanıcı iş akışları) dikkate almaz - ne düşündüğünüzü yorumlarla bana bildirin.

1 süper ağır harita hizmeti:
App Server CPU kullanımı =% 49.4
Veritabanı Sunucusu CPU kullanımı =% 7.6
Ağ yükü = 16 Mbps
Ekran Yanıt Süresi = 0.88 sn

(Görüntüler RC tarafından büyük ölçüde görülebilir ve yeni sekmede açılabilir)

4 lite harita hizmetleri:
App Server CPU kullanımı =% 55.4
Veritabanı Sunucusu CPU kullanımı =% 7.6
Ağ yükü = 64 Mbps
Ekran Yanıt Süresi = her biri 0.32 sn, dolayısıyla web tarayıcısı ek yüklerine bağlı olarak 0.32 ila 1.28 sn.

Bir harita hizmeti yaklaşımını desteklemek için daha fazla mantık:

1. Bu nedenle, tüm katmanlar aynı harita hizmetindedir;
   a. bir istek sunucuya gönderilir
   b. bir SOC süreci haritayı çizer
   c. bir görüntü ağ üzerinden döndürülür

2. 40 katman 4 harita hizmetine yayılmıştır (her biri 10 katman);
   a. 4 istek sunucuya gönderilir
   b. 4 SOC süreçleri bir harita çizer
   c. Ağ üzerinden 4 görüntü döndürülür

1a ve 1c daha hızlı olacak ve ağa 2a ve 2c'den daha az yük koyacaktır.

2b, tek bir kullanıcı için 1b'den daha hızlı bir harita döndürmek için paralel işlemeyi kullanabilir, ancak bu birçok kullanıcı için geçerli olmayacaktır. Aslında, sunucu tarafından 2b'de işlenen ek işlemlerin (artı 2c'nin ek ağ yükü) ek yükü, kullanıcı sayısı arttıkça 1b ölçeğini çok daha iyi görecektir.

Birden çok hizmet kullanmak, katmanları / etiketleri ölçeklendirmek, önbelleğe almak ve dinamik olmayan etiketleri kullanmak web uygulaması deneyimini geliştirmeye yardımcı olsa da, 600+ katmanı tek bir uygulamaya yüklemek için ilk isabet son kullanıcı tarafından fark edilir. Özellikle TOC'u doldurmak için geçen süre. Eğer bir 600+ katman uygulaması oluşturmak zorunda kalırsanız ben kesinlikle # 2 seçeneği ile gider. Veri düzenlemenizi bir veri modeline (yerel yönetim veri modeli gibi) göre modellemek isteyebilirsiniz .

Aşağıdaki tanıtım belgesi, ArcGIS Server web uygulaması yapılandırmaları için bazı ilginç en iyi uygulama yönergelerini ve performans istatistiklerini vurgulamaktadır.

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