最近何故か・・・
SSLオフロードの記事が良く読まれています。
昨今の証明書の実装が標準化しそうな流れに合わせてですかね。A10に限らず、F5のIPでも出来ますし、なんでだろ・・・（？－？と思っています。
話していたつもりで話していなかったし、実際の効果ってどうなの？っていうのがタイトルの「コンテンツ圧縮」ですね。
実データサイズの半分に圧縮してデータがお届けできるなら、その分ロードタイムは速くなるので、結果的にページの表示が早いとなるので、インターネット回線の帯域とスループットの関係とは別に、帯域とスループットに貢献できる手段の一つです。
Akamaiさんとかだと、画像なんてAkamaiのサービスで圧縮してやりますよ・・・って具合ですが、ロードバランサ―だってただラウンドロビンして順当負荷するだけじゃなく、色々な機能をハイエンドロードバランサ―は持っています。
一部抜粋になりますが、確認した時の結果値ね。
用途を語るにはちょーっと難しいのですが、一番下の圧縮効率の悪かったものは、画像や動画を扱っているサーバーです。あとはWEBアプリだと思ってください。
因みにコンプレッションレベルは10段階中の９で、圧縮レベルでいうと「ほんのり圧縮でスピード重視」です。
圧縮もし過ぎてはコンテンツが何時まで経っても送信できない（レスポンス低下）になってしまったり、アプリに不具合がでてしまうかもなので、兎に角簡易圧縮して送信っ！みたいなレベルですね。
でもかなりのデータセーブ率ですよね。
CPUには余力はあるのでもう一段階圧縮率を上げても良いような気がしますが、このセーブ率で今は満足です。
なので、この圧縮率でアクセスすると、WEBサーバーに直接アクセスするよりもロードバランサ―を経由した方がレスポンスが早くなるという事になりますね。
AWSなどのELBではこのような圧縮はないので、パブリッククラウドの場合はサードパーティ製LBを投入すればコンテンツ圧縮出来ると思います。
最近は、SSL証明書の自動更新を組み込むサーバーもあって、
「SSL暗号負荷はロードバランサ―がやらんでも今のハードは大丈夫！」
なんていうケースも増えているようなんですが、コスト追及のバランスは其々ってことで（ ＾ω＾）・・・。
このネタを書いたのもインターネットの遅延に対して打つ手としての一つかなと思ってね。。。
