低遅延のプロキシでもダウンロードが遅い理由
接続の遅延とダウンロードのスループットは、プロキシへのリクエストの異なる部分を測ります。用途に合った方法でテストしましょう。
小さなページをすぐに返すプロキシでも、ファイルのダウンロードは遅いことがあります。最初のリクエストで主に分かるのは、接続の確立や応答の遅延です。大きな転送では、その経路で継続して運べるデータ量も影響します。
どの数値が目的に合うか
| 用途 | 見るべき指標 |
|---|---|
| 小さなページを開く、短いAPIリクエストを送る | 接続の確立を含め、応答を受信するまでの時間。 |
| ファイルをダウンロードする | 適切なテストファイルで測った総転送バイト数と平均スループット。 |
| 多数のリクエストでもアプリの応答性を保つ | 想定負荷での通常の応答時間、失敗、接続の再利用。 |
ICMPのpingは別のテストです。サーバーはプロキシサービスが使えなくてもpingには応答する場合があり、プロキシが正常でもpingを遮断する場合があります。プロキシのアドレスまでの往復時間には、プロキシから目的の接続先までの接続も含まれません。
実際の転送を測る
自分で管理するサーバー上のファイルか、この種のテスト用のファイルを使います。次の例はレスポンス本文を破棄し、転送量、1秒あたりの平均バイト数、合計時間を表示します。
curl --proxy http://203.0.113.10:8080 --noproxy '' --connect-timeout 5 --max-time 30 --silent --show-error --output /dev/null --write-out 'status=%{http_code} bytes=%{size_download} average_Bps=%{speed_download} seconds=%{time_total}\n' https://example.com/test-file.bin例のプロキシとファイルのURLは両方とも置き換えてください。404ページやアクセス拒否の応答は、すぐに届いても有効なダウンロードの測定にはなりません。速度を比較する前に、ステータス、想定ファイルサイズ、内容を確認します。
平均速度の欄の単位はバイト毎秒です。ビット毎秒で表示される回線プランとは単位が異なります。バイトからビットへの概算には8を掛け、比較全体で同じ単位を使ってください。
比較条件をそろえる
接続先、ファイル、クライアントのネットワーク、タイムアウト設定をそろえます。最速の試行だけを選ばず、無理のない規模で複数のサンプルを比較してください。転送が止まる場合は、接続確立、全体の時間、低速状態の制限を意識して選びます。失敗したリクエストも結果に残します。ときどき速くても頻繁に失敗するプロキシは、完了が必要な処理には向かない場合があります。
キャッシュされたファイルと新しいダウンロードでは、サービス内部で通る経路が異なることがあります。接続確立後のリクエストと既存の接続を再利用するリクエストも同様です。アプリに必要な動作を決め、その動作を一貫した条件で測定します。
処理内容に合わせて選ぶ
小さなAPIレスポンスなら、最大スループットよりも最初の1バイトまでの余分な1秒が重要な場合があります。大きなダウンロードでは、ハンドシェイクだけ速く、その後の本文が極端に遅いのは割に合いません。どちらの場合も実際に使う接続先でテストしてください。プロキシを通るすべての経路を表す、単一の速度スコアはありません。
ProxyHubのプロキシ一覧は、IPごとの独立したスループット測定値を提供していません。プロトコルや国による絞り込みは速度のランキングではありません。