- ホーム
- ベンチマーク
IDM 対 MDM、ミリ秒単位で計測。
両方のアプリを同じPCにインストールし、同じテストサーバーから交互にダウンロードしました。サーバー自身のログには、各リクエストがいつ到着し、最後のバイトがいつ送信されたかが記録されているため、どちらのアプリの報告にも依存していません。
競争
1.0倍速い
中央値からリアルタイムで再生。
あらゆるシナリオで高速。
MDMがコマンドからファイル完了までにかかった時間の速さ。ひげは比率の95%区間を示し、スケールは対数です。
2接続に対し480接続。
一度に2つの接続を許可するサーバー。各四角は、典型的な実行でサーバーが認識した1つの接続です。
サーバーの応答から制限を学習し、それを守り、次回のために記憶します。12.6秒で完了しました。
拒否に対して1秒間に約250回再試行しました。15.9秒で完了しました。
すべての実行が1つの点です。
各アプリで7回以上実行された7つのダウンロード。棒グラフは実行の中央半分、線は中央値を示します。
IDMは、コマンドラインからダウンロードを受け付けてからデータを送信するまでに約3秒かかります。ブラウザ拡張機能で取得されたダウンロードでは、この手順はスキップされます。そのため、「転送」が公平なエンジン間の比較となります。「エンドツーエンド」もここにあります。
時間の内訳
各アプリのシナリオごとの起動(コマンドから最初の要求まで)、転送、完了の中央値。
コンピューターへの負荷
各アプリが実行中に使用したCPU時間の中央値と、そのピークメモリ。MDMはGPUでウィンドウを描画するため、IDMの従来のWindowsコントロールよりも多くのメモリを使用します。
すべての数値
| シナリオ | アプリ | n | エンドツーエンド、中央値 (IQR) | 中央値の95%信頼区間 | 転送 | 起動 | 接続数 | リクエスト数 | CPU | ピークメモリ | p |
|---|
レポート
四分位範囲を含むエンドツーエンドの中央値、95%信頼区間を含む比率、およびtools/bench/report.pyが記述するマン・ホイットニー検定。
| シナリオ | IDM中央値 ms (IQR) | MDM中央値 ms (IQR) | IDM / MDM (95% CI) | p (マン・ホイットニー) |
|---|---|---|---|---|
| 高速ローカルリンク経由で1 GiB | 5456 (5393–5496) | 1009 (944–1028) | 5.41× (5.21–5.89) | 0.000583 |
| 100 MiB、接続あたり2 MB/秒 | 10234 (10221–10284) | 6319 (6317–6329) | 1.62× (1.61–1.63) | 0.000583 |
| 100 MiB、150ミリ秒の遅延、接続あたり4 MB/秒 | 7622 (7497–7863) | 3844 (3842–3894) | 1.98× (1.92–2.05) | 0.000583 |
| 32 MiB、128 KB/秒で3回のクロールで1接続 | 7213 (6960–7256) | 3432 (3416–3840) | 2.10× (1.81–2.13) | 0.000583 |
| 50 MiB、サーバーは2接続を許可、それぞれ2 MB/秒 | 15864 (15810–15933) | 12568 (12563–12570) | 1.26× (1.25–1.27) | 0.000583 |
| 50 MiB、2 MiB後に2番目の接続が切断、4 MB/秒 | 5428 (5387–5466) | 1647 (1645–1660) | 3.30× (3.24–3.34) | 0.000583 |
| 高速ローカルリンク経由の256 KiBファイル | 3141 (3130–3164) | 30 (28–31) | 105.90× (99.96–112.75) | 3.39e-06 |
第13世代 Intel(R) Core(TM) i5-13400F、63.8 GB RAM、Windows-11-10.0.26200-SP0。labserver (このリポジトリ)、127.0.0.1:8097、生成されたコンテンツ。両方ともデフォルト設定:8接続。
測定方法
- サーバー。 このリポジトリのラボサーバーで、127.0.0.1上で生成されたコンテンツを提供します。シナリオごとに接続をスロットリング、遅延、拒否、または切断し、すべてのリクエストをミリ秒単位の開始時刻と終了時刻でログに記録します。
- クライアント。 IDMとMDMはどちらもデフォルト設定(8接続)で、同じ文書化されたコマンドライン
/d URL /p folder /f name /nを介してダウンロードを実行します。両方ともIDMの一時フォルダーがあるドライブに保存するため、クロスドライブコピーのコストはかかりません。 - タイミング。 エンドツーエンド:コマンドの発行から最終的な名前のファイルが完成するまで、単調なクロックでミリ秒ごとにポーリングされます。MDMは完成したファイルを所定の位置にリネームします。IDMは最終ファイルを早期に作成して埋めるため、IDMの場合はフルサイズに達した瞬間がカウントされます。転送:サーバーの最初のリクエストから最後のバイトまで、各実行前にキャリブレーションリクエストを介して同じクロックで読み取られます。
- 公平性。 アプリは交互に実行され、偶数回はIDMが最初、奇数回はMDMが最初になるため、マシンのドリフトは両方に影響します。各ウォームアップ実行は破棄されます。失敗した実行はカウントされ、破棄されません。各実行の前に、ハーネスはループバックが静かになるまで待機します。追加の接続を拒否するサーバーに対して、IDMは1秒あたり約250回再試行し、数千の閉じたソケットを30秒間残します。待機しないと、次に実行されたアプリはそのバックログで時間を計られてしまいます。
- 統計。 メディアンと四分位範囲、各メディアンおよびメディアンの比率に対するブートストラップ95%信頼区間(10,000リサンプル)、および両側マン・ホイットニーU検定。
- 制限。 ループバックリンクには実際の距離やパケット損失はありません。障害はそれらを代用します。結果は1台のマシンからのものです。ご自身で実行してください:
python tools/bench/bench.py、次にpython tools/bench/report.py。
ご自身でお試しください。無料です。
Mister Download Managerをダウンロード