どうやって計測しているか

再現できない数値は主張であって、データではありません。何をどう測っているかを全部書きます。

計測環境

対象ホストの選び方

各社が公開している計測用のエンドポイントのみを対象にしています。無関係なサーバーに ping を撃つことはしません。

実機で測っているもの

契約しているインスタンス上では、公開エンドポイントからは取れないデータが取れます。

ディスクI/O

fio による実測です。direct I/O（OSのキャッシュを迂回）で、512MBのファイルに対して各パターン15秒ずつ実行しています。

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のロスが必ずしも実トラフィックのロスを意味しない点には注意が必要です。

計測スクリプト

実際に動かしているものです。依存は標準ライブラリのみです。

# 対象ホストは 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  # 特定の会社だけ

出力は 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 で遅延が確認できます。

免責

掲載している数値は特定時点・特定環境での計測結果です。各社のネットワーク構成やピアリングは随時変更されるため、将来にわたって同じ結果になることを保証するものではありません。契約前には自分の環境での確認を強くおすすめします。

よくある質問