Banyak lapisan dalam satu atau beberapa layanan? (dan mengapa)


13

Saya memiliki teka-teki bahwa saya mendapatkan saran yang beragam tentang bagaimana caranya. Karenanya saya ingin memasukkannya ke GIS-SE untuk mendapatkan jawaban yang tepat.

Skenario:

  • Klien memiliki aplikasi pemetaan web. Tidak ingin dipecah menjadi beberapa aplikasi yang lebih kecil. Meskipun hal ini bertentangan dengan pendekatan modern untuk peta di web, (yaitu banyak aplikasi peta web yang difokuskan pada satu peta web utama) saya sangat percaya bahwa bagi beberapa pengguna, mencoba mereplikasi aplikasi GIS di web adalah ok ( kadang-kadang ).

  • Klien telah meng-cache sebanyak mungkin layer peta dasar ke layanan terpisah.

  • Klien masih memerlukan 600-700 lapisan tambahan dalam layanan peta dinamis ...
  • Layanan akan dipublikasikan dengan semua lapisan ini dimatikan .
  • Tidak diantisipasi bahwa pengguna akan menyalakan lebih dari 10-40 lapisan sekaligus.

Saya membayangkan reaksi awal Anda terhadap ini mirip dengan saya (600+ ?! WTF ?!)

Namun - persyaratan diatur dalam batu dan mengapa tidak? Aplikasi ArcIMS mereka sebelumnya memiliki fungsi yang sama, jadi mengapa produk Server ArcGIS yang lebih baru ini tidak dapat melakukan hal yang sama? Para pengguna berpotensi perlu untuk dapat membandingkan silang dan melakukan analisis pada seluruh jajaran lapisan, bahkan jika lapisan itu milik departemen lain.

Sebelum Anda langsung mengambil kesimpulan, klien adalah admin ArcGIS Server yang telah diberi petunjuk.
Mereka telah mengelola 600 lapisan dengan semua aturan praktik terbaik: misalnya rentang skala dikombinasikan dengan permintaan definisi; anotasi atas pelabelan; generalisasi lapisan kompleks pada skala kecil; mempublikasikan sebagai MSD; dll

Masalah :

Apa pendekatan yang lebih baik di sini?

  1. Publikasikan semua 600 lapisan ke dalam satu layanan peta dinamis

  2. Membagi lapisan menjadi pengelompokan logis (hidrologi, perencanaan, ekologi, utilitas, dll)

Jika Anda menggunakan # 1, dan Anda memiliki beberapa lapisan kompleks yang dihidupkan. Jika Anda ingin mengaktifkan lapisan poin sederhana, maka ArcGIS Server masih harus membuat seluruh lapisan ditampilkan lagi.

Jika Anda menggunakan # 2, setiap kali Anda membuat permintaan, secara potensial, aplikasi web harus membuat beberapa permintaan GET untuk ExportMaps dari masing-masing layanan peta (apakah ini buruk, atau apakah itu membuat beban tambahan ke ArcGIS Server di atas # 1 ?)

Dan kemudian ini mengarah ke konfigurasi & penyetelan untuk memastikan semuanya secepat mungkin. Kita dapat mengatur bagian belakang ArcGIS Server ke beberapa host dan memiliki beberapa perangkat keras yang baik untuk digunakan.

Jika Anda memilih # 1, Anda bisa melempar # jumlah instance AGS yang bisa Anda tangani.

Jika Anda menggunakan # 2, saya berasumsi Anda mengevaluasi kinerja layanan peta (pengujian beban dan lihat waktu tunggu) dan alamat instance min / max yang sesuai untuk memastikan tidak ada satu layanan yang merupakan 'tautan lemah'.

Saya saat ini condong ke pendekatan # 2, karena kepala saya masih mengatakan kepada saya bahwa memiliki 600 lapisan dalam satu layanan adalah kegilaan, tetapi jika semuanya dimatikan secara default, benar-benar tidak ada masalah.

Senang mendengar pikiran Anda. Beri tahu saya jika Anda memerlukan info lebih lanjut melalui komentar, tetapi tidak mencari jawaban seperti 'gunakan aplikasi desktop' atau 'mendidik mereka untuk melakukan sesuatu secara berbeda'


Dari diskusi dalam komentar, saya gagal menyebutkan pertimbangan lain. Aplikasi tempat layanan tersebut akan dikonsumsi, memiliki kemampuan untuk keamanan tingkat lapisan (pada tingkat aplikasi). Oleh karena itu grup pengguna (yang cukup besar) ditugaskan untuk peran tertentu, dan peran itu akan memiliki akses ke 600 lapisan penuh. Peran lain akan terbatas.


Secara pribadi, saya akan mengajukan pertanyaan kepada PM yang menguraikan masalah, memberi saran tentang praktik terbaik, menyarankan jalan keluar, lalu meninggalkannya di tangan mereka. Pada akhirnya, segera setelah seseorang berkata: 'tapi memang begitu,' tangan Anda penuh. Dalam situasi ini, saya akan melakukan seperti di atas, maka Anda sudah profesional, melakukan pekerjaan Anda, dan sisanya terserah mereka. Saya juga menyarankan untuk memasukkan siapa pun yang kaya dan terkenal dalam hal di mana Anda bekerja, di email, untuk memastikan saran itu ada di luar sana, dan bahwa semua orang tahu apa sarannya, dan siapa yang memberikannya.
Hairy

Anda tidak mengatakan jenis webapp yang akan digunakan untuk menelusuri lapisan, tapi saya berasumsi bahwa itu adalah jenis openlayers. Dalam hal ini perlu diingat bahwa browser juga dapat menghadirkan masalah, karena tidak akan mengeluarkan lebih dari beberapa (antara 2 dan 6) permintaan bersamaan ke server yang sama (termasuk XHR, css dan semuanya). Lihat artikel ini untuk rincian dan beberapa alternatif (saya biasanya pergi untuk beberapa CNAMEs ketika TI adalah koperasi): stevesouders.com/blog/2008/03/20/...
unicoletti

@Hairy - Saya benar-benar berpikir bahwa kita dapat memenuhi persyaratan klien dengan ArcGIS Server, dan meskipun mendorong batas pada apa yang mungkin terjadi dengan AGS, masih bisa dilakukan, dan kita masih bisa kembali pada saran kami sebelumnya untuk memecahkan aplikasi menjadi beberapa aplikasi.
Simon

1
Saya tahu ini bisa dilakukan, saya telah bekerja dengan klien yang melakukan hal yang sama, tetapi saya tidak berpikir itu disarankan, yang merupakan hal yang berbeda. Jika mereka memutuskan untuk memiliki 10 klien yang ingin semua 600 lapisan, pada satu waktu, apa pun yang Anda jalankan AGS, itu akan jatuh
Hairy

Jawaban:


8

Menggunakan Alat Perencanaan Kapasitas untuk membantu membandingkan satu layanan peta super berat vs 4 peta layanan lite, dan hasilnya menunjukkan bahwa layanan peta berat adalah cara untuk pergi.

Ini mungkin bukan jawaban yang tepat, dan alat perencanaan kapasitas tidak memperhitungkan setiap faktor (misalnya alur kerja pengguna) - beri tahu saya melalui komentar apa pendapat Anda.

1 layanan peta sangat berat:
Penggunaan Server Aplikasi Server = 49,4%
Server Database Penggunaan CPU = 7,6%
Beban jaringan = 16 Mbps
Waktu Respons Layar = 0,88 dtk

(Gambar dapat dilihat dalam jumlah besar dengan RC dan buka di tab baru)

masukkan deskripsi gambar di sini

Layanan 4 lite map:
Penggunaan Server Aplikasi Server = 55,4%
Server Database Pemanfaatan CPU = 7,6%
Beban jaringan = 64 Mbps
Tampilan Waktu Respons = masing-masing 0,32 detik, jadi antara 0,32 dan 1,28 detik tergantung pada overhead browser web

masukkan deskripsi gambar di sini

Lebih banyak logika untuk mendukung pendekatan layanan satu peta:

  1. Semua lapisan berada dalam layanan peta yang sama, oleh karena itu;
    Sebuah. satu permintaan dikirim ke server
    b. satu proses SOC menggambar peta
    c. satu gambar dikembalikan melalui jaringan

  2. 40 lapisan tersebar di 4 layanan peta (masing-masing 10 lapisan), oleh karena itu;
    Sebuah. 4 permintaan dikirim ke server
    b. 4 proses SOC menggambar peta
    c. 4 gambar dikembalikan melalui jaringan

1a dan 1c akan lebih cepat dan lebih sedikit memuat jaringan daripada 2a dan 2c.

2b dapat menggunakan pemrosesan paralel untuk mengembalikan peta lebih cepat dari 1b untuk satu pengguna, tetapi ini tidak akan menjadi masalah bagi banyak pengguna. Bahkan, overhead dari transaksi tambahan yang sedang diproses oleh server dalam 2b (ditambah beban jaringan tambahan 2c) akan melihat skala 1b jauh lebih baik karena jumlah pengguna meningkat.


2
itu terdengar logis. Mengelola 600-layer MXD tidak terdengar menyenangkan.
Stephen Lead

1

Meskipun menggunakan beberapa layanan, penskalaan lapisan / label, caching, dan penggunaan label non-dinamis semua membantu meningkatkan pengalaman aplikasi web, klik awal untuk memuat semua 600+ lapisan ke dalam satu aplikasi akan terlihat oleh pengguna akhir. Terutama waktu yang dibutuhkan untuk mengisi TOC. Jika Anda harus membuat aplikasi 600+ layer saya pasti akan pergi dengan opsi # 2. Anda mungkin ingin memodelkan struture data Anda terhadap model data (seperti model data pemerintah daerah).

Papan tulis di bawah ini menyoroti beberapa pedoman praktik terbaik yang menarik dan statistik kinerja untuk konfigurasi aplikasi web ArcGIS Server.

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


Poin bagus di TOC, tetapi sebenarnya memuat dengan baik. 'hit awal untuk memuat 600+ lapisan' = dari perspektif permintaan peta, masih hanya membuat satu permintaan ke satu layanan. Jadi sebenarnya cukup cepat bagi AGS untuk mengembalikan ekspor SAMPAI mereka mulai membalik> 20 lapisan.
Simon
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.