ようへい

2012年12月6日木曜日

Bloggerでのデータファイル置場に関する検証と考察

Googleのブログサービス、BloggerではJavaScript、スタイルシート等の静的ファイルをサーバにアップロードする機能が無い。
つまり、これらのファイルは別のサーバにホスティングする必要がある。
ホスティングするサーバに関して検証を行い考えてみた。
あくまで個人的な考えです。

発端

私は今までGoogle App Engineにファイルをホスティングしていたのだが、先日(といっても結構前)、Google App Engineで数時間に及ぶ接続障害が発生し、私のブログが閲覧できない状態になってしまった。
これは、head内でGoogle App Engineのファイルを参照していたため。

ホスティングサービス

Google Site
無料で利用でき、かつGoogleが提供しているサービスとして、Google Siteがある。
Google Siteでは、ファイルアップロード機能も用意されているため、Google Siteにアップロードし、そのファイルをBloggerにて参照するという方法。
アップロードもGUIが用意されているため比較的簡単にできる。
また、ファイルの世代管理も可能。
Google App Engine
こちらも無料で利用できるGoogleのサービス。
少々知識は必要だが、自由度も高く、アプリケーションも開発できる。
ファイルのアップロードは、コマンドラインやEclipseなどによるデプロイという方式をとるため、手間がかかる。
また、ときどき障害が発生し、ファイルが参照できなくなる。
ファイルが参照できないと、最悪の場合、Bloggerの閲覧が不可能になる。(head内でGoogle App Engineのファイルを参照している場合など)
オンラインストレージ
Dropboxや、SugarSyncなどにファイルをアップし、パブリックリンク機能を利用する方法。
ファイル管理は楽にできる。
また、ファイルの世代管理も可能。
但し、レスポンスが悪い時もある。

検証

Google Site、Google App Engine、Dropbox、SugarSyncにファイルを置いて、レスポンス時間を計測。
head内でGoogle App Engineのファイルを参照するのは懲りたのだが、改めてどの程度の応答か確認してみる。
置くファイルは、100KB(102,400Byte)のJavaScriptファイル。
計測する環境は、以下
  • Windows 7 64bit
  • Google Chrome 23
計測は、Google Chromeのデベロッパーツール(Ctrl+Shift+I)のNetworkにて行う。
また、デベロッパーツールにて、ブラウザのキャッシュを無効化(Disable cache)した。
計測後、HARファイルとしてエクスポートし、集計しました。

単位はミリ秒です。
Google Site
(リダイレクト)
Google Site
(ファイル取得)
Google Site
(リダイレクト+ファイル取得)
Google App Engine SugarSync Dropbox
1回目 312 277 589 549 613 1295
2回目 342 269 611 512 595 1273
3回目 260 263 523 720 589 2043
4回目 271 439 710 559 565 1220
5回目 281 267 548 816 948 1463
6回目 324 240 564 669 757 1700
7回目 256 275 531 655 822 1596
8回目 294 572 866 562 1011 1336
9回目 295 315 610 561 804 1541
10回目 324 458 782 748 527 1323
平均値 296 338 633 635 723 1479
中央値 295 276 600 609 685 1400
最小値 256 240 523 512 527 1220
最大値 342 572 866 816 1011 2043
検証で分かったこと
Google Site
Google のサービス内(Blogger、Google App Engine等)からであれば、ファイルを読み込むことが可能。
ただし、直接読み込めるわけではなく、リクエスト»Auth keyの発行»リダイレクト»ファイル読込 となるため、2回目のリクエストでようやくファイルを読み込むことができる。
Google App Engineと比較すると、稼働率は高いと思う。
レスポンスで返されるファイルは、Content-Encoding:gzipとなっており、ファイルが圧縮されているため、通信量の節約が行われているので、レスポンスも早い。
Last-Modified,Etag,Cache-Control(max-age=1, must-revalidate)ヘッダによってキャッシュ制御が行われている点も良い。
Google App Engine
ファイルを直接読み込むことが可能。
Google Siteと同じようにContent-Encoding:gzipによってファイルを圧縮して返してくれる
しかし、Google Siteより稼働率は低いと思う。
ファイルに付与するヘッダや、キャッシュの有効期限を任意に設定できるという点で、自由度は高い。
SugarSync
ファイルを直接読み込むことが可能。
レスポンスは若干遅め。
Google Siteと同じようにContent-Encoding:gzipによってファイルを圧縮して返してくれる
Last-Modified,Etag,Vary(Accept-Encoding)ヘッダによってキャッシュ制御も行われる。
障害は少ない。
Dropbox
ファイルを直接読み込むことが可能。
レスポンスはかなり遅い。
なぜなら、Google Site、Google App Engine、SugarSyncと異なり、gzip圧縮してくれないため、通信量が多くなる。
他と比べて、倍の時間がかかっている。
Cache-Control:max-age=0となっているため、ファイルは常にサーバから取得される
レスポンスが遅いうえに毎回問い合わせとなるため、最悪。
障害は少ないがオススメしない。

総評

今回の検証ではGoogle Siteが一番良さげ。
早速head内で読み込んでいるファイルをGoogle App EngineからGoogle Siteに変更しました。
Dropboxは意外に残念な結果でした。

他に検証してほしいホスティングサービスがあれば、コメントにて教えてください。
ただし、パブリックリンクが取得できるホスティングサービスに限ります。
Google Drive、SkyDrive、Boxは現時点でパブリックリンクに対応していません。
関連記事

0 件のコメント:

コメントを投稿