HTTP2Conference #http2conf

2014/11/03にIIJにて行われたHTTP2Conferenceのツイートまとめです。 イベントリンク: http://http2study.connpass.com/event/9209/ ライブ配信 https://www.youtube.com/channel/UClAm9N6cUlmaPZ_laTKHT0Q
11
前へ 1 ・・ 3 4 ・・ 30 次へ
tehishik @tehishik

HTTP1.0で標準じゃなかったんや #http2conf

2014-11-03 12:30:56
Kaoru Maeda 前田 薫 @mad_p

Ilya: HTTP/1.1が1999年にRFCとして標準化された。15年経ってもまだ使われている #http2conf

2014-11-03 12:31:29
Kaoru Maeda 前田 薫 @mad_p

Ilya: HTTP/1.1が入ったときはGeocitiesの時代だった。覚えてる? いまはWebアプリは進化していろいろ変わっている。モバイル対応もしている。 #http2conf

2014-11-03 12:32:18
tehishik @tehishik

平均して、一回のルクエストで12のサーバに接続に行く、78のリクエストを出す、結果1MB位の転送が行われ、2-6秒くらいの時間がかかる。おっそい #http2conf

2014-11-03 12:33:34
Kaoru Maeda 前田 薫 @mad_p

Ilya: HTTP世界のメディアン(中央値)的なページはこんなだ。12 ホスト/ページ、78リクエスト/ページ、1,232KB/ページ。50%値で2.6秒、90%値で5.6秒かかる。とても遅い #http2conf

2014-11-03 12:33:34
Rintaro @_rintaro_f

レンダに。2.6-5.6 秒。とても遅い。 #http2conf

2014-11-03 12:33:42
matsuu @matsuu

#http2conf 本題と関係ないが、応答時間として50〜90パーセンタイルを例示してたけど、そこらへんの値を提示するのが良い指標なんだろうか。

2014-11-03 12:35:20
tehishik @tehishik

次はWeb page viewがいかにUsefulか。まずはBandwidth。次にTransfer time。BWがボトルネックでない場合もある #http2conf

2014-11-03 12:35:25
Kaoru Maeda 前田 薫 @mad_p

Ilya: connection viewで見ると実際のバイト転送よりも接続して最初のバイトまでを待つ時間が長い。ほとんどのwebページは4Gでつないでも速くならないが、こういう理由 #http2conf

2014-11-03 12:36:06
mod @speedmod

.@mad_pさんの実況が非常にありがたいので規制はちょっと待ってほしい #http2conf

2014-11-03 12:36:23
tehishik @tehishik

GoogleでAnalyticsベースでTop3000(?)のサイトに対してテストを実施。パフォーマンスのボトルネックは何か。70%がネットワークのブロックタイム。ここに改善が必要 #http2conf

2014-11-03 12:37:07
Kaoru Maeda 前田 薫 @mad_p

Ilya: トップ3000サイトをロードしてみて何に時間がかかるか測定してみた。70%の時間はネットワーク待ち。次が6.6%がJavaScript待ち。最適化するべきはネットワークである #http2conf

2014-11-03 12:37:15
tehishik @tehishik

SPDYやQUICはこのために設計されている #http2conf

2014-11-03 12:37:33
Moto Ishizawa @summerwind

このパフォーマンス問題の説明の流れ、めちゃくちゃ納得感ある。仕事での説明にも使えるのでよく覚えておこう。 #http2conf

2014-11-03 12:38:20
Kaoru Maeda 前田 薫 @mad_p

Ilya: 実際の問題は並列性にある。HTTP/1.1にはHTTP Pipelineがあるが、ほとんどのブラウザではデフォルトで禁止されている。その結果、クライアント/サーバーで1往復ごとに待っている。6本までのconnectionは並列化できるが #http2conf

2014-11-03 12:38:24
matsuu @matsuu

#http2conf Maximum of 6 requests per originって書いてるが、最近のIEとかもっと同時コネクション張ってる気がする。気のせいかもしれないけど。

2014-11-03 12:38:56
Kaoru Maeda 前田 薫 @mad_p

Ilya: 通信の単位は小さくなっているのでハンドシェイクのオーバーヘッドも大きくなっている #http2conf

2014-11-03 12:39:06
tehishik @tehishik

ほかのHackの説明。ドメイン接続が限られるなら、ドメインを共有すればよいのでは? うまくいかない、TCPをすっげーパラレルにしてもだめ。最適な並列数は何?ということがわからない。これはコンテンツとかページに依存するから #http2conf

2014-11-03 12:40:50
Kaoru Maeda 前田 薫 @mad_p

Ilya: あるサイトの実例として、15並列接続してみた。TCP接続のcongestion controlによって2倍量のデータを送信することがわかった #http2conf

2014-11-03 12:40:55
Kaoru Maeda 前田 薫 @mad_p

Ilya: この結果を反映して、chromeは画像を10個までしか並列にダウンロードしないようにした #http2conf

2014-11-03 12:41:24
Kaoru Maeda 前田 薫 @mad_p

Ilya: リクエストを減らすため、小さなコードを集めて大きなファイルにした。しかし問題がある。CSSルールのうち20%しか使われない。少し変えただけでcacheが効かなくなってしまう。JSS/CSSが届くのが遅くなるので描画開始が遅くなってしまう #http2conf

2014-11-03 12:43:22
tehishik @tehishik

次のHack。CSSスプライト的な。これもうまくいきそうでだめだった。ふつうはいろんなページがリソースを共有するので、キャッシュがうまくいかない。Gmailとかでも実行ファイルが大きくなってしまってうまくいかない #http2conf

2014-11-03 12:43:50
Yosuke Furukawa @yosuke_furukawa

Reduce number of requests が如何に有効かっていう話、この辺は本にも書いてあったな。 #http2conf

2014-11-03 12:44:05
matsuu @matsuu

#http2conf Expensive cache invalidationsってconcatした場合にexpensiveになるってことか

2014-11-03 12:44:22
前へ 1 ・・ 3 4 ・・ 30 次へ