ArcGIS for Serverフィーチャの受取


ArcGISに限らずGISサーバには、以下の2つの選択肢が用意される

  • 画像をサーバで作成する
  • 画像をクライアント側で描画させる(ブラウザ描画)

そして描画処理は、GISサーバにとって編集などと比較して最も負荷が高い処理にして基本機能
(バッチ編集でもない限りは、1レコードのやり取り対話処理なので問題にならない)

◆サーバ描画 [メリット]
データ量がレコード数に依存しない
描画速度がブラウザ(クライアント機能)に依存しない
高度な描画コンポーネントを使用可能 (サーバ側ライブラリは比較的自由)
◆サーバ描画 [デメリット]
サーバCPU負荷がクライアント描画に比べて高い(許容人数が減る)

◆クライアント描画 [メリット]
サーバCPU負荷がサーバ描画に比べて低い(許容人数が増える)
◆クライアント描画 [デメリット]
データ量がレコード数に依存 (通信負荷によって許容人数減の可能性あり)
描画速度がブラウザ(クライアント)に依存(低性能マシンやAndroid端末等ではつらい場合も)
描画コンポーネントがあまり選べない(シンボル表現に制限が生まれやすい。網掛け等)

基本的には、サーバ描画の方が優位ではあるがクライアント描画も選択肢とする必要がある。
理由は下記

  • HTML5等選択肢が増えている
  • サーバ描画の根源的なCPUリソース枯渇に対する対処はマシン増加しかない

クライアント描画の場合は、100人同時なら少なくとも100コア確保できる(まあ理論上)
サーバ描画はコア数は固定で製品によって縛りがあり。。
タイル画像化がベストっちゃベストだが、編集必要なレイヤの場合いずれにせよ選ぶ必要あり

サーバ描画周りの話は以下でもしているので興味がある人は
MXD速度調整
ArcGIS for Serverのインスタンス数とサービス数

という訳でまだ少量のレコードしか使い物にならないクライアント描画を少しでも速くしようと少し検証してみた話。
ArcGISではFeatureLayerの概念、個人的にはレコード数にして1000程度が限界だと思っている(頂点数にもよるが)


ArcGISではRest Json形式でデータをやり取りする
ArcGIS REST API
http://resources.arcgis.com/en/help/rest/apiref/

例えば白地図の日本地図 (5.5万頂点 1.9千レコードほど )のJsonをテキスト保存時(全属性入り)には21.5MBにもなる。
動的ZIp圧縮(Gzip圧縮)が効いたとして、よくて8MB程度か?

頂点数だけでも理論値で
double 8byteとして属性を省いて
4322.9609375KByte × 2 (Z値なしのXYとして)
約 8MBになる計算

とりあえず、あまり高速化できそうにないが容量削減と独自にレスポンス返却することによって
処理時間の内訳を確認して後日また考えようかと。

Flexは容量削減のためAMF(ActionScript Message Format)というバイナリを使う。

とりあえずGoogle Protocol Buffers化してみる。
protobuf-jsというJavascript実装も.NET用もあり情報も豊富なので。

.NET用のProtocol Buffers
https://code.google.com/p/protobuf-net/

結果 (単位は秒)

自作 ArcGIS直アクセス
1.96 10.59
2.35 9.88
2.06 10.17

データソースはSQL Server 2012に入った同一テーブル=白地図の日本地図 (5.5万頂点 1.9千レコードほど )
ん?なんか内容に関わらずやけにArcGIS遅いような。。
自作のほうはカラムヘッダとか出してはないけど。
ちなみに上記に追加で、クライアント側で使用するクラスへのパースが必要

肝心のデータ容量は10.8MBほどなので50%くらいにはなっている。

同一マシンで、WebRequestからレスポンス受取までWindowsアプリで測定
自作は、.NET WCF RESTにてレスポンス返却

さらに内訳
クライアント処理

処理内容 秒数
Webリクエスト受取 2.69
ProtoBuf.Serializer.Deserialize: 0.90
Runtime WPF Graphicsインスタンス化 1.88

上記クライアントのWebリクエスト受取のサーバ側処理の内訳 (同一マシンだけあって通信コストがほぼないのが分かる)

処理内容 秒数
DataTable取得 0.82
ProtoBuffer用クラス インスタンス化 1.16
ProtoBuf.Serializer.Serialize 0.68

なにか長くなってきたので、コードと考察はまた別途

ここに続き

カテゴリー: 開発, 設計 タグ: , パーマリンク