アカウント名:
パスワード:
パフォーマンスネタなので、専門でやっている立場でコメントします。
1. DNSは世界的にパフォーマンスが遅延傾向にある
アメリカのパフォーマンス業界でホットな話題はDNSの遅延で、DNSのパフォーマンス改善は急務となっています。
現状のパフォーマンスは、ここが参考になるかと。http://www.dnsperf.com/ [dnsperf.com]
2. USENのスピードテスト、BNRスピードテストは、CDNとは関係無い
サイトそのものはCDNを使ってますが、スピードテストで通信している先はCDNを使っていないです。Wireshark、Microsoft Network Monitor、Firebug、Developer Tool、どれを使っても良いのですが、モニタリングツールを使えばわかります。
USENは、sp.usen.com、BNRは、suite3.musen-lan.comとv3.musen-lan.com。なので、DNSのIPを見て最寄りのエッジサーバから通信してるわけじゃないです。
3. DNSのパフォーマンス計測のデータが掲載されていない。
DNSに遅延の原因があるというのであれば、まずはDNSのパフォーマンスの計測を行うべきでしょう。スピードテストがDNSの遅延に影響されているという因果関係を説明するための実験が行われていません。
4. そもそもDNSの名前解決の時間は計算に含まれていない
USENのサイトに以下のように記載されています。
「複数サイズのデータを実際にダウンロードし、そのダウンロードにかかった時間から1秒あたりにどれだけのデータをダウンロードできているかを調べます。ダウンロードしたデータ量÷ダウンロードに要した秒数＝回線速度となります。」
BNRのサイトに以下のように記載されています。
「本サイトの測定方法は、実際にテストサーバーからのデータを受信することにより、実際の通信速度を計測しております。」
USENのテストの場合は、33.7KB、85.0KB、1.1MB、2.8MB、9.8MB、20.2MBの順でファイルをダウンロードしています。
BNRのテストの場合は、118.2KB、236.4KB、472.6KB、774.9KB、1.5MB、3.0MBの順で、最初にsuite2.musen-lan.com、次にv3.musen-lan.comとサーバを変えて2回計測しています。
Flashのソースコードがどう書かれているのか分かりませんが、もし万が一、DNSのLookup時間が含まれていたとしても、最初のファイルのダウンロードの時点で、ローカルキャッシュされるので、パフォーマンスに多大な影響を及ぼすとは考えにくいです。
5. WiFi経由でテストをしてはいけない
WiFiの通信環境は、通信状況が大きくブレるため、外部との通信速度テストに使うには、不適切です。変数を減らすため、有線回線を使うべきです。
6. 数回のテストでは、数学的に何も証明できない
何回計測したのか分かりませんが、記事から察するに1回か2回というところでしょうか?「たまたま、そうなっただけ」と言われても仕方がないです。
統計学で、信頼区間という概念があります。同じ調査をやったとしたら、どの位の確率で同じ結果になるか、というものです。
ちゃんと実験計画法に基いて実験・計測すべきですが、ラフに調べるにしろ、20～30回は計測してみるべきです。何故なら、必ず、計測にはブレが生じるし、外れ値も発生します。最低でも、最速値と最遅値を外して計算するトリム平均を求めてないと…ちゃんとやるなら、ヒストグラムとか、箱ひげ図ぐらい作らないと。
7. ダウンロード時間の最も影響を与えるのは、途中経路
サーバ側にボトルネックが無いと仮定した場合、ダウンロード時間に最も影響を与えるのは途中経路です。ホップ数と、各ホップのパケットドロップ率、レイテンシです。まず、何よりも、経路検証をしないと、この手のテストは意味がありません。
下のレイヤーから徐々に上のレイヤーへと上がっていくのが、この手の試験の一般規則です。
先日、Computer Measurement Groupの2015年度のMichelson Awardを、ワシントン大学のRaj Jain教授が受賞されたんですが、Jain教授が書かれた「The Art of Computer Systems Performance Analysis: Techniques for Experimental Design, Measurement, Simulation, and Modeling」という本があります。
ワシントン大学では20年以上、パフォーマンス計測の教科書として使われています。Jain教授は、ネットワーク通信の計測とパフォーマンスのモデリングの権威ですし、この本の第二版が近日中に発売されますので、それを読んでから実験されて記事にされては如何かと。
この手の計測試験について、やり方を詳細に解説しておられます。
私としては、たまたまそういう計測値になっただけだろうし、DNS関係ないし、一番影響があったのはWiFiの通信状況じゃないの?って見解です。
DNSで負荷分散をやってるという話なのに、IPアドレスじゃなくてドメインがこれだからCDNではないって言えるんですか？
#なんかやたらとCDNっていう証拠は証拠はって頑張ってる人がいるみたいだけど
まともに答えるべきかどうか、少し迷いました。
結論から言うと、専業でやってるんで、そういうのを判別するツールがあるんですよ。皆さんが使えるのだと、BuiltWith(http://builtwith.com/)というのがあります。それを使えば、簡単に判別できます。
さて、ツールだけで終わらせると、あまりエンジニアとしては良質な回答じゃないと思うので、もう少しRawなやり方を書きます。
対象となるサーバに対して、tracerouteをされましたか?そうすれば、経路が分かります。するとですね、東京のKDDIとNTTの回線2つからTracerouteしてみると、このサーバの手前にあるのは、125x63x33x13.rev.usen.ne.jpと125x63x33x130.rev.usen.ne.jpというサーバなんですよ。まぁ、それだけでも、分かるんですが、もう少し、証拠を積み重ねましょう。
Akamai時代に習ったのですが、ネットワークの三角法というのがあってですね、幾つかのサーバ(IPでもいいです)が、物理的に同じ場所にいるのか、違う場所にいるのかを判別するやり方なんですよ。
異なる幾つかのASからTracerouteをかけたときに、同一のGatewayに接続されてホストに辿り着いた場合、物理的に同一のデータセンターにそのサーバが存在すると分かるわけです。
さて、日本から、このsp.usen.comにTracerouteをした場合と、ロンドンからTracerouteをかけた場合、CDNを使っているなら、異なるGateway、異なるサーバIPに辿り着くはずです。でも、全く同じなんです。
もしかしたら、たまたま、同一になったかもしれないですか?それでは、南米のベネズエラからTracerouteをかけてみます。同じです。
タイからTracerouteをかけてみます。同じです。CDNの契約で、配信対象が日本国内だけかもしれませんね。では、大阪のOCNからTracerouteをしてみます。同じです。
つまり、異なるASネットワーク6箇所からTracerouteをしても同じ場所に辿り着くわけです。故に、USENのデータセンターにこのサーバは置いてあり、(分散配置型の)CDNは使っていないと断定できるのです。
それにですね、この手の試験にCDNを使っていたら、まっとうな試験ではなくなってしまいますよね。倫理的に。
商売的にも、「あなたの使ってる回線、遅いですよ。乗り換えませんか?」というマーケティングのリード集めが目的のサービスですから、CDNを使って高速化したら、問い合わせが得られないじゃないですか。
丁寧な解説ありがとうございます。
CDNか否かについての判別方法についてはなんとなくイメージはあったのですが、配信対象地域も考慮しなければならないのですね。とても勉強になります。
じゃあなんでモニタリングツールでわかる、ドメインを根拠にCDNじゃないなんて言ったんですか？
まず、スピードテストのページでFlashを使い通信しているわけですから、どのホストと通信をして、ファイルのダウンロードをしているかを確定する必要がありますよね?
だから、モニタリングツールが必要になるわけです。
それで、ホストが確定したら、そのホストがCDNサービスのものなのか、それとも普通のサーバなのかを確定するわけです。
私は、元の説明で、ドメインを根拠にしていないですよね。ホスト名を根拠にしています。
通信先のホストが確定できれば、生のHTTP Headerを見て確認するもよし、面倒であれば、ツールを使うもよし、tracerouteの経路から判断するもよし、です。
ほうぼうからtracerouteしてみるのを「ネットワークの三角法」というのか。勉強になりました
・公開DNSやISPのDNSなど複数の手段で名前を引いて一致するかを確認・普通にDNSで引いてCDN系のドメインにCNAMEされていないか確認・DNS逆引きしてみてCDN系のドメインになっているかを確認・tracerouteしてみてCDNっぽいネットワーク経路になっているか確認
確定ではないけどこの辺の手段である程度推測はできて、複数の特徴がスカだったからCDNでは「なさげ」といえる。これ以上を求めるならCDNであると主張する側にも相応の根拠がほしいわな。
元記事、再設定するだけで速度が変わるとかも書かれてるからCDNって説ではコレを説明できないし。
参考にはなるのですが、元ネタの人は真面目にパフォーマンス計測する意図は無いと思いますよ？ネットワーク遅い → DNS変えたら早くなった っていう単なる日記を記事にした物ですよね。
「ネットワーク遅い→DNS変えたら早くなった」という内容が根本的に間違っているから、ここまで話題になってるのだと思いますが。
でも、話がSoftBankだとしたら、・ipv6は遅くなるのでわざとDNSから外してある。・それに対して、8888はipv6が第一選択。の違いは有るのでは？
根拠となるデータは？
「ネットワーク遅い」：事実「DNS変えた」：事実「早くなった」：事実
何一つ間違ってない。
「風邪を引いた」：事実「祈祷してみた」：事実「風邪が治った」：事実
何一つ間違っていない。しかし、因果関係は証明されていない。
> モニタリングツールを使えばわかります。Chromeとかの開発者ツール→Networkタブでも(Flash経由通信も)わかりますよ。usenのだと調査後にページ遷移してログ見えなくなるので時間勝負だったですが。
> 私としては、たまたまそういう計測値になっただけだろうし、DNS関係ないし、> 一番影響があったのはWiFiの通信状況じゃないの?って見解です。ルータの再起動の影響を指摘する人も居ますし不明な点は多いですが、この件限定ならDNSやCDNは余り関係がないのはまず間違いなさ気ですね。一般論ならDNSのネットワーク距離やCDNの誤解決で遅くなる可能性も充分あるんですけど。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
皆さんもソースを読むときに、行と行の間を読むような気持ちで見てほしい -- あるハッカー
考察 (スコア:5, 参考になる)
パフォーマンスネタなので、専門でやっている立場でコメントします。
1. DNSは世界的にパフォーマンスが遅延傾向にある
アメリカのパフォーマンス業界でホットな話題はDNSの遅延で、DNSのパフォーマンス改善は急務となっています。
現状のパフォーマンスは、ここが参考になるかと。
http://www.dnsperf.com/ [dnsperf.com]
2. USENのスピードテスト、BNRスピードテストは、CDNとは関係無い
サイトそのものはCDNを使ってますが、スピードテストで通信している先はCDNを使っていないです。Wireshark、Microsoft Network Monitor、Firebug、Developer Tool、どれを使っても良いのですが、モニタリングツールを使えばわかります。
USENは、sp.usen.com、BNRは、suite3.musen-lan.comとv3.musen-lan.com。
なので、DNSのIPを見て最寄りのエッジサーバから通信してるわけじゃないです。
3. DNSのパフォーマンス計測のデータが掲載されていない。
DNSに遅延の原因があるというのであれば、まずはDNSのパフォーマンスの計測を行うべきでしょう。スピードテストがDNSの遅延に影響されているという因果関係を説明するための実験が行われていません。
4. そもそもDNSの名前解決の時間は計算に含まれていない
USENのサイトに以下のように記載されています。
「複数サイズのデータを実際にダウンロードし、そのダウンロードにかかった時間から1秒あたりにどれだけのデータをダウンロードできているかを調べます。
ダウンロードしたデータ量÷ダウンロードに要した秒数＝回線速度となります。」
BNRのサイトに以下のように記載されています。
「本サイトの測定方法は、実際にテストサーバーからのデータを受信することにより、実際の通信速度を計測しております。」
USENのテストの場合は、33.7KB、85.0KB、1.1MB、2.8MB、9.8MB、20.2MBの順でファイルをダウンロードしています。
BNRのテストの場合は、118.2KB、236.4KB、472.6KB、774.9KB、1.5MB、3.0MBの順で、最初にsuite2.musen-lan.com、次にv3.musen-lan.comとサーバを変えて2回計測しています。
Flashのソースコードがどう書かれているのか分かりませんが、もし万が一、DNSのLookup時間が含まれていたとしても、最初のファイルのダウンロードの時点で、ローカルキャッシュされるので、パフォーマンスに多大な影響を及ぼすとは考えにくいです。
5. WiFi経由でテストをしてはいけない
WiFiの通信環境は、通信状況が大きくブレるため、外部との通信速度テストに使うには、不適切です。変数を減らすため、有線回線を使うべきです。
6. 数回のテストでは、数学的に何も証明できない
何回計測したのか分かりませんが、記事から察するに1回か2回というところでしょうか?
「たまたま、そうなっただけ」と言われても仕方がないです。
統計学で、信頼区間という概念があります。同じ調査をやったとしたら、どの位の確率で同じ結果になるか、というものです。
ちゃんと実験計画法に基いて実験・計測すべきですが、ラフに調べるにしろ、20～30回は計測してみるべきです。何故なら、必ず、計測にはブレが生じるし、外れ値も発生します。
最低でも、最速値と最遅値を外して計算するトリム平均を求めてないと…
ちゃんとやるなら、ヒストグラムとか、箱ひげ図ぐらい作らないと。
7. ダウンロード時間の最も影響を与えるのは、途中経路
サーバ側にボトルネックが無いと仮定した場合、ダウンロード時間に最も影響を与えるのは途中経路です。ホップ数と、各ホップのパケットドロップ率、レイテンシです。
まず、何よりも、経路検証をしないと、この手のテストは意味がありません。
下のレイヤーから徐々に上のレイヤーへと上がっていくのが、この手の試験の一般規則です。
先日、Computer Measurement Groupの2015年度のMichelson Awardを、ワシントン大学のRaj Jain教授が受賞されたんですが、Jain教授が書かれた「The Art of Computer Systems Performance Analysis: Techniques for Experimental Design, Measurement, Simulation, and Modeling」という本があります。
ワシントン大学では20年以上、パフォーマンス計測の教科書として使われています。Jain教授は、ネットワーク通信の計測とパフォーマンスのモデリングの権威ですし、この本の第二版が近日中に発売されますので、それを読んでから実験されて記事にされては如何かと。
この手の計測試験について、やり方を詳細に解説しておられます。
私としては、たまたまそういう計測値になっただけだろうし、DNS関係ないし、一番影響があったのはWiFiの通信状況じゃないの?って見解です。
Re: (スコア:0)
DNSで負荷分散をやってるという話なのに、IPアドレスじゃなくてドメインがこれだからCDNではないって言えるんですか？
#なんかやたらとCDNっていう証拠は証拠はって頑張ってる人がいるみたいだけど
Re:考察 (スコア:5, 参考になる)
まともに答えるべきかどうか、少し迷いました。
結論から言うと、専業でやってるんで、そういうのを判別するツールがあるんですよ。
皆さんが使えるのだと、BuiltWith(http://builtwith.com/)というのがあります。
それを使えば、簡単に判別できます。
さて、ツールだけで終わらせると、あまりエンジニアとしては良質な回答じゃないと思うので、もう少しRawなやり方を書きます。
対象となるサーバに対して、tracerouteをされましたか?
そうすれば、経路が分かります。
するとですね、東京のKDDIとNTTの回線2つからTracerouteしてみると、このサーバの手前にあるのは、125x63x33x13.rev.usen.ne.jpと125x63x33x130.rev.usen.ne.jpというサーバなんですよ。
まぁ、それだけでも、分かるんですが、もう少し、証拠を積み重ねましょう。
Akamai時代に習ったのですが、ネットワークの三角法というのがあってですね、幾つかのサーバ(IPでもいいです)が、物理的に同じ場所にいるのか、違う場所にいるのかを判別するやり方なんですよ。
異なる幾つかのASからTracerouteをかけたときに、同一のGatewayに接続されてホストに辿り着いた場合、物理的に同一のデータセンターにそのサーバが存在すると分かるわけです。
さて、日本から、このsp.usen.comにTracerouteをした場合と、ロンドンからTracerouteをかけた場合、CDNを使っているなら、異なるGateway、異なるサーバIPに辿り着くはずです。
でも、全く同じなんです。
もしかしたら、たまたま、同一になったかもしれないですか?
それでは、南米のベネズエラからTracerouteをかけてみます。同じです。
タイからTracerouteをかけてみます。同じです。
CDNの契約で、配信対象が日本国内だけかもしれませんね。
では、大阪のOCNからTracerouteをしてみます。同じです。
つまり、異なるASネットワーク6箇所からTracerouteをしても同じ場所に辿り着くわけです。
故に、USENのデータセンターにこのサーバは置いてあり、(分散配置型の)CDNは使っていないと断定できるのです。
それにですね、この手の試験にCDNを使っていたら、まっとうな試験ではなくなってしまいますよね。倫理的に。
商売的にも、「あなたの使ってる回線、遅いですよ。乗り換えませんか?」というマーケティングのリード集めが目的のサービスですから、CDNを使って高速化したら、問い合わせが得られないじゃないですか。
Re: (スコア:0)
丁寧な解説ありがとうございます。
CDNか否かについての判別方法についてはなんとなくイメージはあったのですが、配信対象地域も考慮しなければならないのですね。
とても勉強になります。
Re: (スコア:0)
じゃあなんでモニタリングツールでわかる、ドメインを根拠にCDNじゃないなんて言ったんですか？
Re:考察 (スコア:2)
まず、スピードテストのページでFlashを使い通信しているわけですから、どのホストと通信をして、ファイルのダウンロードをしているかを確定する必要がありますよね?
だから、モニタリングツールが必要になるわけです。
それで、ホストが確定したら、そのホストがCDNサービスのものなのか、それとも普通のサーバなのかを確定するわけです。
私は、元の説明で、ドメインを根拠にしていないですよね。
ホスト名を根拠にしています。
通信先のホストが確定できれば、生のHTTP Headerを見て確認するもよし、面倒であれば、ツールを使うもよし、tracerouteの経路から判断するもよし、です。
Re: (スコア:0)
ほうぼうからtracerouteしてみるのを「ネットワークの三角法」というのか。勉強になりました
Re: (スコア:0)
・公開DNSやISPのDNSなど複数の手段で名前を引いて一致するかを確認
・普通にDNSで引いてCDN系のドメインにCNAMEされていないか確認
・DNS逆引きしてみてCDN系のドメインになっているかを確認
・tracerouteしてみてCDNっぽいネットワーク経路になっているか確認
確定ではないけどこの辺の手段である程度推測はできて、
複数の特徴がスカだったからCDNでは「なさげ」といえる。
これ以上を求めるならCDNであると主張する側にも相応の根拠がほしいわな。
元記事、再設定するだけで速度が変わるとかも書かれてるからCDNって説ではコレを説明できないし。
Re: (スコア:0)
参考にはなるのですが、元ネタの人は真面目にパフォーマンス計測する意図は無いと思いますよ？
ネットワーク遅い → DNS変えたら早くなった っていう単なる日記を記事にした物ですよね。
Re:考察 (スコア:2)
「ネットワーク遅い→DNS変えたら早くなった」という内容が根本的に間違っているから、ここまで話題になってるのだと思いますが。
Re: (スコア:0)
でも、話がSoftBankだとしたら、
・ipv6は遅くなるのでわざとDNSから外してある。
・それに対して、8888はipv6が第一選択。
の違いは有るのでは？
Re: (スコア:0)
根拠となるデータは？
Re: (スコア:0)
「ネットワーク遅い」：事実
「DNS変えた」：事実
「早くなった」：事実
何一つ間違ってない。
Re:考察 (スコア:2)
「風邪を引いた」：事実
「祈祷してみた」：事実
「風邪が治った」：事実
何一つ間違っていない。しかし、因果関係は証明されていない。
Re: (スコア:0)
> モニタリングツールを使えばわかります。
Chromeとかの開発者ツール→Networkタブでも(Flash経由通信も)わかりますよ。
usenのだと調査後にページ遷移してログ見えなくなるので時間勝負だったですが。
> 私としては、たまたまそういう計測値になっただけだろうし、DNS関係ないし、
> 一番影響があったのはWiFiの通信状況じゃないの?って見解です。
ルータの再起動の影響を指摘する人も居ますし不明な点は多いですが、
この件限定ならDNSやCDNは余り関係がないのはまず間違いなさ気ですね。
一般論ならDNSのネットワーク距離やCDNの誤解決で遅くなる可能性も充分あるんですけど。