WCFの転送量

MVCの仕事はまだ来ません。なのでその間に別の仕事の対応をやっているわけですが。

このシステムはWCFサービスをサーバーに置き、地図を利用したWindowsアプリとAndroidアプリが場所（座標）を追加したり編集したりするんですが、どうも起動時に場所を読み込んでくる部分が遅く気になっていました。もちろん稼働当初より数は増えているので当然の話しかもしれませんが、それを差し引いてもモッタリ感が強くて。

正直原因は転送量なんだろうなと予想はついていました。
場所データの公開はEntity経由のRESTサービスでビューを丸々公開しています。Windowsアプリはサービス参照で、Androidアプリは自作ライブラリでこのデータを利用するわけですが、このデータ取得の転送量がえらいことになってました。JSONでも7M、XMLに至っては倍の15Mほどでした。ぎゃー。

これはマズイっしょということで現在修正中なのですが原因をいくつか。

ユニークURLが勝手に付く

配信されるデータ全てにユニークURLがつきます。これがハンパな量じゃない。結局その部分を何にも使うわけではないので無駄以外の何物でもありません。

漢字の使用

社内にはデータベースのテーブル名、フィールド名に漢字を使う傾向があります。これに関しては全く異論は無くむしろ支持派です。シンボリックだと本来の意味に置き換える脳内変換の時間や、資料を漁らないとわからないという無駄な時間ができてしまうので。でもこれが仇となってエンコードされた文字列がこれまた半端じゃない量で降ってしまうわけです。

余計な項目まで降っている

ビューとして使用しているので条件だけに使用したい項目も含まなければいけず、それを丸々公開してるもんで降ってからの処理には使わないものまで降らしています。これも無駄。

改行コード、空白の付加

JSONには付いてないようでしたが、XMLの場合改行コード2バイトと意味不明の空白が付加されています。これもまたすごい量。Minifyが当然、セミコロンの1バイトも圧縮する時代に雑すぎるでしょ、みたいな。

以上が原因。これを解決するためにやること。

WEBメソッドの利用

WEB API使えよってツッコミは無しで。きちんと配信に必要な項目だけのクラスを作成してDataMember属性のNameで限りなく項目名を短くします。さらに場所の名称や漢字の使用されているような項目は排除しキー項目、経度緯度ぐらいにして、名称等の情報は必要なときにまた引くことにします。たくさん引いてもクリックされて内容を見られるのは僅かなのでこれでも大丈夫そうです。これでユニークURL、漢字、余計な項目はなくなります。そしてSOAP通信にすることによって無駄な改行、空白は抑えられます。

参照にしか使用することがないビューはADO.NET Data Servicesでの公開は向いていない・・・というかやったところで嬉しい部分が実は少ないかなと感じました。というわけで修正続けます。