sidetech

インフラエンジニアの寄り道メモ。

イギリスからダウンロードが重い言われても(涙)

またまた海外拠点からのネタ。やっと解決したと思ったら今度はイギリスから、うちのシステムにアップされている画像のダウンロードが重くて話にならんというご連絡が入りました。

提供しているシステムのアプリはTOMCATで書かれたシステムで、日本で使う分には問題ない。こう言った事は距離と環境でよく出てくる話。しかし、日本は一般家庭にも光回線が引けちゃう御国です。ジャブジャブの回線事情ですが、海外ではそんな国はそうそうないです。xDSLやCATVがまだまだ全盛です。でも大抵は遅いのは日本のせいにされます(苦笑)

とりあえずインフラ屋としてはイチャモンつけられた訳なので、キッチリしてやろーじゃねーかぁと。

さて、自分が日本にいてシステムも日本にあって現地の状況がわからないし時差あるし、どうやって(ある程度)正確なテストをしたり改善を見出したりすればいいでしょうか。

そんな時に頼るサイトが以下のサイト。
『WebPageTest.org』

Webpagetest
色々な国のロケーションから何種類かのブラウザでURLアクセスしてパフォーマンスを測るサイトです。私はこのサイトをある程度のベンチマークとして自社環境のインフラのパフォーマンスの参考値にしたり色々活用しています。

イギリスは日本からすれば殆ど裏側の国だからね。日頃から最低でも300msがデフォだと頭じゃわかっています。しかし、実際はレスポンス値にデータ量が乗っかってきますので、嫌でも日本エリアよりも画像のロードが重たくなったりするのはわかりますが、でも本当はどこがあかんのかを考える前に自設備の提供のパフォーマンスはインフラだけじゃどうにもならないアプリの作りにも関わってきます。でもそこを意識出来るのはグローバル環境に常に晒されている人達だけじゃないかな・・・と。私もまだまだ勉強中です。

で、現在届いている話では、700KBの画像ファイルがダウンロードに3分程度要しているとのこと。単純に考えると、拠点のネット回線が遅いと考えたいのですが、果たしてサーバーサイドのインフラはバッチリなのでしょうか。

今回提供しているサービス環境の中のインフラでロードバランサーを使用しています。A10ネットワークス社のサンダーシリーズでTH1030Sを使用しています。
ハイエンド系なロードバランサーではSSLオフロードやらRAMキャッシュ・圧縮などなど、冗長性や負荷分散だけではない機能が提供されています。

その中で今回ご紹介するのは「HTTP圧縮」機能です。
Th1030comp01
TEXTやJAVAScript、画像などが配信されるときに更に圧縮が掛かっていると、インターネット使用帯域を減らすことが出来ますので、それだけレスポンスアップが期待出来ます。ただ、圧縮技術は限度もあり、掛け過ぎても圧縮時間が掛かり過ぎて、そもそものレスポンスタイムが遅くなってしまう可能性もあります。

とりあえず四の五の言わずに結果をWEBPAGETESTの画像と結果でお伝えしますと。。。

まず最初はHTTP圧縮機能を使わなかった場合。
Th1030comp02
注目すべきはLoadTimeとCompressの判定ですね。CompressTransferが「F」判定です。
CompressImagesについては「JPG」が対称なようなので今回は無視w。

そしてHTTP圧縮を使用した場合。
Th1030comp03
判定がA判定になりました。よーく見比べるとわかるのですが、cssファイルやjsファイル、jspファイルの圧縮が行われてコンテンツロードタイムが短縮されています。

Compresult
なんでFAILEDになっているのか調べてないけど、どの位圧縮が掛かっているのかがログに記録されています。
ざっと70KB分はHTTP圧縮機能でダイエットしたってことになりますね。
大きな数値には見えませんが、海外相手ではこういった地味な数値もレスポンスアップに貢献します。

そしてWEBPAGETESTのリザルトをみると、約1秒の短縮。ま、1秒程度は揺らぎもあるのでなんともですが。。。(涙)
このWEBPAGETESTではもう一ついいことというか、アプリ屋に考えてほしい部分が見えてきます。
バーグラフを見比べると・・・6番の.js以降から.pngのロードがはじまっていますよね。まぁ見ての通りプログラムを読み込んで初めて動く部分と動的にロードしていく部分と様々です。そういった情報もバーグラフで一目瞭然。オシロ的にいうとタイミングチャートみたいな(余計わからんて)。
なので、とっととスクリプトを読み込んであげないと、ページが真っ白なのでダイエットは体感的にも効果が出るはずなんです。Onloadが実際の表示ステップの部分かと思います。

そして、このWEBPAGETESTで無駄にPNGファイルサイズがデカいものが分かったので、WEBアプリ担当者に「TinyPNG」とか圧縮API関連を紹介してとりあえず圧縮してと言ったり。

で、あとここまでやってもまだ自サイトでのチューニングなので、実際にレスポンスがインフラ的に問題ないかを、有名なサイトもTESTして比較したりして現状のインフラでは値がわるくなかったんでホッとした所です。

で、とりあえずあとは現地の回線パフォーマンスがどんな感じかを調査するだけですね。

なんかWEBPAGETESTの紹介みたいになっちゃったな・・・。