Насколько точен «текущий курс» CURL в индикаторе прогресса?

Question

Достаточно ли точен второй вывод в скручивании? На какой период рассчитывается "текущий курс"?

В настоящее время я использую выходной сигнал состояния «второй-второй» в Curl в качестве общего показателя текущей пропускной способности для этого соединения.

Если вы не знаете, что означает этот "вывод статуса", то нет смысла описывать его :-)

Я считаю, что это "достаточно хорошо" ... выборочные тесты показали, что это довольно близко, но я хочу убедиться. Кроме того, текущая скорость в секунду за последнюю секунду? Я предполагаю, что так, хотя руководства кажутся несколько неясными по этому поводу.

Answer 1

Я посмотрел на этот вопрос несколько дней назад и должен сказать, что иногда удивлялся тому же. Кстати, это не так точно, когда вы анализируете его на уровне пакетов. Кроме того, даже значения в выходных данных о состоянии противоречат друг другу. См. Ниже, например:(проверьте значения текущей скорости в байтах / сек и соотнесите их со средней скоростью загрузки и полученными данными в байтах)

% Total     % Received % Xferd  Average Speed   Time    Time     Time  Current
                                Dload  Upload   Total   Spent    Left  Speed
0     0     0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
0     0     0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
2 10.0M     2  234k    0     0   161k      0  0:01:03  0:00:01  0:01:02  161k
7 10.0M     7  769k    0     0   314k      0  0:00:32  0:00:02  0:00:30  314k
10 10.0M   10 1102k    0     0   319k      0  0:00:32  0:00:03  0:00:29  319k
16 10.0M   16 1671k    0     0   368k      0  0:00:27  0:00:04  0:00:23  368k
23 10.0M   23 2371k    0     0   435k      0  0:00:23  0:00:05  0:00:18  480k
28 10.0M   28 2905k    0     0   450k      0  0:00:22  0:00:06  0:00:16  534k
31 10.0M   31 3269k    0     0   434k      0  0:00:23  0:00:07  0:00:16  492k
38 10.0M   38 3973k    0     0   470k      0  0:00:21  0:00:08  0:00:13  574k
43 10.0M   43 4476k    0     0   473k      0  0:00:21  0:00:09  0:00:12  569k
47 10.0M   47 4814k    0     0   459k      0  0:00:22  0:00:10  0:00:12  486k
54 10.0M   54 5571k    0     0   486k      0  0:00:21  0:00:11  0:00:10  533k
59 10.0M   59 6089k    0     0   474k      0  0:00:21  0:00:12  0:00:09  532k
63 10.0M   63 6522k    0     0   478k      0  0:00:21  0:00:13  0:00:08  492k
68 10.0M   68 6992k    0     0   481k      0  0:00:21  0:00:14  0:00:07  496k
74 10.0M   74 7599k    0     0   485k      0  0:00:21  0:00:15  0:00:06  536k
80 10.0M   80 8255k    0     0   489k      0  0:00:20  0:00:16  0:00:04  494k
84 10.0M   84 8648k    0     0   491k      0  0:00:20  0:00:17  0:00:03  535k
89 10.0M   89 9202k    0     0   493k      0  0:00:20  0:00:18  0:00:02  534k
95 10.0M   95 9745k    0     0   495k      0  0:00:20  0:00:19  0:00:01  536k
100 10.0M 100 10.0M    0     0   507k      0  0:00:20  0:00:20 --:--:--  584k

Теперь посмотрите на аналитическую сводку трассировки анализатора первой и второй секунды этого потока по отношению ко всему потоку на рисунках ниже: (Разница между этими значениями и выводом состояния curl действительно замечательна)

Первая секунда:

Вторая секунда:

Я полагаю, что это доказывает тот факт, что отчеты о скручивании не являются точными, но они служат цели более или менее. Средние значения, которые он сообщает, усредняются за последние 5 секунд с пятой секунды, и даже средний расчет не является точным.

Еще один момент, на который стоит обратить внимание, это то, как curl всегда показывает скорость загрузки как 0, тогда как трассировка сниффера показывает, что средняя скорость загрузки составляет около 22558 байт / с для этой 20-секундной транзакции 11 МБ.

Надеюсь, это поможет!