どうやって計測しているか
再現できない数値は主張であって、データではありません。何をどう測っているかを全部書きます。
計測環境
| 項目 | 内容 |
|---|---|
| 計測地点 | 東京(データセンター内) |
| 計測ノードの回線 | Contabo Asia(AS141995)東京リージョン |
| 計測手法 | ICMP echo(ping)+ MTR による経路解析 |
| ping回数 | 15回 |
| MTR回数 | 5回 |
| タイムアウト | 1パケットあたり3秒 |
| 実行頻度 | 1日1回まで |
対象ホストの選び方
各社が公開している計測用のエンドポイントのみを対象にしています。無関係なサーバーに ping を撃つことはしません。
| サービス | 使用しているホスト |
|---|---|
| Vultr | hnd-jp-ping.vultr.com(東京)、osk-jp-ping.vultr.com(大阪) |
| Linode | speedtest.tokyo2.linode.com、speedtest.osaka.linode.com |
| Oracle Cloud | objectstorage.ap-tokyo-1.oraclecloud.com ほか |
| Hetzner | sin-speed.hetzner.com、fsn1-speed.hetzner.com ほか |
| DigitalOcean | sgp1.digitaloceanspaces.com、nyc3.digitaloceanspaces.com |
実機で測っているもの
契約しているインスタンス上では、公開エンドポイントからは取れないデータが取れます。
ディスクI/O
fio による実測です。direct I/O(OSのキャッシュを迂回)で、512MBのファイルに対して各パターン15秒ずつ実行しています。
| パターン | 内容 |
|---|---|
| ランダム読み 4K | データベースなど小さいランダムアクセス |
| ランダム書き 4K | ログ書き込み、トランザクション |
| 連続読み 1M | 大きいファイルの読み出し、モデルのロード |
| 連続書き 1M | バックアップ、大きいファイルの書き込み |
python3 scripts/bench.py --provider contabo --region tokyo --plan "Cloud VPS"
結果は data/measurements/bench-<provider>-<region>.json に保存されます。
CPU
依存ライブラリなしの簡易ベンチです。整数演算をシングルスレッドと全コアで回し、所要時間を記録します。
意図的に測っていないもの
データの範囲を明示しておきます。
帯域(スループット)
測っていません。継続的に大容量ファイルをダウンロードすることは、公開エンドポイントであっても相手に負荷をかけます。帯域は自前で契約したインスタンス上でのみ計測する方針です。
特定ISPからの経路品質
計測ノードは1箇所のみです。「モバイル回線からだけ遅い」といったISP依存の問題は、この計測では検出できません。将来的に複数の計測地点を用意する予定です。
数値の読み方
RTT(往復遅延)
平均値に加えて、最小値とゆらぎ(mdev)も併記しています。平均が同じでもゆらぎが大きい経路は不安定です。トレードBotのようにレイテンシの安定性が効く用途では、平均よりゆらぎを見てください。
ホップ数
MTRで到達した経路のホップ数です。応答しないホップ(???)も経路長には数えますが、末尾に連続する無応答は除外しています。
ホップ数が多いこと自体は問題ではありませんが、同じ距離でホップ数が大きく違う場合は経路設計の差を示します。実測ではLinodeの大阪リージョンが17ホップと他社の2倍近くありました。
パケットロス
0%以外が出た場合は経路上の問題を示します。ただしICMPは優先度を下げて扱うネットワーク機器があるため、ICMPのロスが必ずしも実トラフィックのロスを意味しない点には注意が必要です。
CDNの後ろにあるホストをどう測るか(3層に分ける)
VPSリージョンへの計測は ping と MTR で足ります。相手が生のホストだからです。しかし取引所やFX業者のホストはCDNの後ろにいることが多く、そこに ping を打つと返ってくるのは利用者の近くにあるCDNエッジです。この値は距離の指標になりません。
当サイトはここを3層に分けて記録し、混ぜて1つの数字にしません。
| 層 | 何を測っているか | 使い道 |
|---|---|---|
| edge | ICMP ping / MTR。手前のCDNエッジまで | 「エッジが近くにある」ことの確認だけ。順位付けには使えない |
| app | 接続を維持したままのHTTP往復 | 利用者(Bot)が実際に待たされる時間 |
| region | 世界の観測点から、オリジンまで必ず往復するリクエストのTTFB | どのリージョンに置くべきかの判断 |
「オリジンまで必ず往復するリクエスト」には、エッジがキャッシュから返せないものを選びます。たとえば GET /info に対してオリジンが 405 Method Not Allowed を返すエンドポイントなら、エッジは打ち返せず必ずオリジンまで行きます。応答ボディが空なので回線速度の影響も受けません。
WebSocketを使うサービスでは、さらに配信間隔を測ります。往復レイテンシが1msでも、板の配信が5秒に1回なら支配的なのは後者だからです。この計測は依存パッケージを増やさないため標準ライブラリだけで書いてあります(scripts/measure-hyperliquid.py)。
家庭・一般回線から見た値(Globalping)
計測ノードはDC内にあるため、家庭回線より一貫して良い値が出ます。そこで外部の公開プローブ網(Globalping)からも測り、両方を併記しています。
🔴 観測点は日替わりです。 同一観測点の時系列比較には使えません(同一計測内の会社間・地点間の比較のみ成立します)。またプローブ側の事情で1回の値は数十msぶれるため、複数回測って最小値を採り、近接した観測点どうしの順位は読ませない表記にしています。
計測スクリプト
実際に動かしているものです。依存は標準ライブラリのみです。
# 対象ホストは data/targets.json に定義
python3 scripts/measure.py # 通常実行
python3 scripts/measure.py --dry-run # 書き込まずに確認
python3 scripts/measure.py --count 30 # ping回数を変える
python3 scripts/measure.py --only vultr # 特定の会社だけ
# 国内FX業者ホスト(CDN配下かどうかを持ち回る)
python3 scripts/measure.py --targets data/fx-targets.json --prefix fx-
# 家庭・一般回線から見たRTT(Globalping)
python3 scripts/measure-eyeball.py
# Hyperliquid(edge / app / region / WebSocket の4段)
python3 scripts/measure-hyperliquid.py
出力は data/measurements/YYYY-MM-DD.json と latest.json に保存され、サイトのビルド時に読み込まれます。
有効な計測値が1件も取れなかった場合は、既存のデータを保護して書き込みを中止します。ネットワーク障害時に古い正しいデータが空データで上書きされるのを防ぐためです。
自分で測る場合
同じことは手元でもできます。
# 往復遅延
ping -c 15 hnd-jp-ping.vultr.com
# 経路とホップごとの遅延
mtr -r -c 5 hnd-jp-ping.vultr.com
mtr が入っていなければ次で導入できます。
sudo apt install mtr-tiny # Debian / Ubuntu
brew install mtr # macOS
Windowsの場合は tracert で経路が、ping -n 15 で遅延が確認できます。
免責
掲載している数値は特定時点・特定環境での計測結果です。各社のネットワーク構成やピアリングは随時変更されるため、将来にわたって同じ結果になることを保証するものではありません。契約前には自分の環境での確認を強くおすすめします。
よくある質問
計測スクリプトは公開されていますか
はい。このページに掲載しているPythonスクリプトがそのまま実行しているものです。data/targets.jsonに対象ホストを定義し、pingとMTRを実行してJSONに出力します。
なぜ帯域(スループット)を測っていないのですか
帯域計測は相手のサーバーに実質的な負荷をかけるためです。公開されている計測用エンドポイントであっても、継続的に大容量の転送を行うのは適切ではないと判断しました。ディスクI/Oと帯域は、自前で契約したインスタンス上でのみ計測します。
計測はどれくらいの頻度で行われますか
1日1回までとしています。相手側への負荷を避けるためです。データの鮮度は各ページに計測日時として表示しています。