以下斜め読んだ内容

pseudo translation of useful posts, book reviews, remarks,etc. twitter: feeddict

Guy Podjarny「SPDYのベンチマークに寄せられた声へのリプライ」

斜め読み

Guy's Pod 2012.6.20のブログエントリ

Guy's Pod » Blog Archive » SPDY Benchmark – Feedback Highlights

以下斜め読んだ内容
  • 前に出したエントリ。反響たくさん
  • Q：ウェブサイトはhttpに最適化されてるから「spdyは言うほど速くない」という結論が出たんじゃ？
  • A：
    • 一理ある。が、自分のテストの結論に影響無し
    • http時代の高速化tipsであるdomain sharding
      • spdyと相性悪い
    • domain shardingへの対策
      • 自分も取り組んだ経験あり
      • 例。リソースをページと同一ドメインに引越したり
      • だが、引越しは全てを解決しない
      • domain shardingは未だ使われ続けてる
    • 自分のテストで出した結論に影響はない
    • テスト対象にしたサイトが使ってるドメイン数は、平均18個
    • 自社管理ドメイン（1stパーティドメイン）はわずか2-3個、残りは外部サイトドメイン（3rdパーティドメイン）
  • Q：理想は、サイトがspdyに最適化すること
  • A：
    • spdy時代特有の高速化tipsは今後出てくる、かも
    • たいていはhttpの場合でも有効なものが多い
    • domain shardingはhttp時代限定のtips。例外的存在
    • 理想（みんなspdy）への過渡期として、http/spdy両方対応の時期がある
    • http/spdy両方対応できるサイトは、それなりのインフラ持った所じゃないのと難しく、少数派だと
    • 限られたサイトだけがspdyのメリットを存分に享受
  • Q：テストではCDN〜オリジンサーバ間はhttpだった。それではspdyの真価は測れない
  • A：
    • テストおさらい
      • 対象サイト群がspdy対応のリバースプロキシーをフロントに置いてる、かのような状態にした
      • リバースプロキシ役を演じたのがcotendo cdn
      • エッジサーバ（cdn）とオリジンサーバ（対象サイト）の間の通信はhttpだけ
      • cdnのリージョンは東海岸（new york）
    • オリジン〜エッジサーバ間の通信がボトルネックになる？
      • だからクライアント（ブラウザとか）〜エッジサーバ間がspdyだとしても効果が相殺される
      • という想定をしてる人がこういう疑問出してくる
    • この懸念は的外れ。３つ理由ある
      • 1。間にcdn入れたから遅くなるとかありえない
        • cdnはクライアント〜オリジン間の通信高層化のための技術
        • エッジ〜オリジン間のリクエスト多重化とか色々高速化するためのテクニックが投下されてる
        • akamai、cotendoとかに限らずcdn屋がみんなやってること
        • cdnは実績積み重ねてる
      • 2。レイテンシと帯域の平均を比較すれば、オリジン〜エッジサーバ間の方が圧倒的に上
        • モバイルネットワークと比較すると、その差は一番大きくなる
        • テストによれば、モバイルネットワークでもspdyは高速化にそれほど貢献してなかった
      • 3。クライアント〜エッジサーバ間の平均読込時間は、環境によって大きく変わる
        • ケーブルはモバイルの半分以下のレイテンシ
        • cdn〜オリジン間はクライアント〜cdn間がケーブルだろうとモバイルだろうと一定
    • cdnを間においてるからspdyの価値を測りそこねてるという言い草はナンセンス
    • cdn〜オリジン間がspdyだったとしてもテスト結果は変わらない
  • Q：1stパーティのリソースはcdnに全てキャッシュした状態でテストしないとspdyの真価は分からない
  • A：
    • つまり、エッジサーバ〜オリジンサーバ間の通信が実質ゼロ状態でテストすること
    • 懸念に同意できないが、試してもいいテスト方法
    • 現実のケースには無いようなバイアスを色々持ち込むテストでもある
      • cdn〜オリジン間の通信がほぼゼロなんだから、現実よりもリソース読み込みが当然速なった状態でのてスト
      • spdyのパフォーマンスのテスト結果の信頼性を損なう
      • リソースの読込がどれとっても高速なんだったら、リクエスト多重化の効果は軽減するから
  • Q：spdyファーストなサイト設計がデフォルトになれば、3rdパーティのドメインからのリソース読込は消え去るのでは？
  • A：
    • そうなってほしいが、そんな兆しは見えません
    • 益々3rdパーティドメインからのリソース利用は増えてる
    • ソーシャルプラグインとか3rdパーティのドメインのリソース利用がサイトを遅くする元凶なのは一目瞭然
    • ビジネス上の理由で3rdパーティのリソースはサイトに組み込まれてる
    • 3rdパーティのリソース利用の増大が現在の趨勢
    • spdy（http/2.0でもいいけど）はこの趨勢への対応策を含んだ設計になっていくかな、と感じてる
    • 有りそうもない流れを期待しないspdyの変化

まとめ

    • 誤解があるかも。自分はspdyラブ
    • みんながあらゆる手立てを講じてspdyをプッシュすべき
    • spdyが力を発揮できない局面では発揮できるように障害を取り除くべき