Чекеры списков: что мерить, кроме доступности

Гоняю списки через обычный чекер, он рисует зелёную галочку и время отклика. По галочкам всё замечательно, а в боевом прогоне часть строк ведёт себя иначе.

Подозреваю, что мерю одну доступность, и её мало. Что вы гоняете перед тем, как пустить список в работу?

Одно обращение вообще ничего не говорит. Мерить надо серией и смотреть на разброс внутри серии.

Сформулирую списком, у меня чекер писан под свои задачи и там семь замеров на строку.

• время до первого байта отдельно от полного ответа: соединение может ставиться мгновенно, а содержимое ползти;
• медиана и девяносто пятый по серии из десяти обращений, среднее тут врёт больше всех;
• доля отказов в серии: девять из десяти это совсем другая строка, чем десять из десяти;
• поддержка CONNECT, иначе https не пойдёт, хотя обычный http бодро отвечает;
• POST с телом килобайт на пять, у некоторых узлов он режется;
• контрольная сумма ответа с эталонной страницы, где содержимое известно заранее;
• сколько живёт соединение при keep-alive, потому что прогон на тысячу страниц через постоянное пересоединение работает вдвое медленнее.

Последний пункт добрался до меня позже прочих. Строка со средним откликом в две секунды и живучим соединением обгоняет строку с откликом в полсекунды, которая рвёт связь после каждого запроса.

а контрольная сумма зачем? если ответ пришёл, значит всё хорошо

Полина Ждан, затем, что ответ бывает подменённый: вместо страницы приходит заглушка с кодом 200. Чекер видит двухсотку и рисует галочку, а в прогоне пусто.

Эталон удобно держать свой, на своей же страничке, где лежит одна строка. Тогда сравнение тривиальное:

etalon=$(curl -s https://moy-domen.example/probe.txt | sha256sum | cut -c1-16)
while read -r p; do
  got=$(curl -s -x "$p" --max-time 15 https://moy-domen.example/probe.txt | sha256sum | cut -c1-16)
  [ "$got" = "$etalon" ] && echo "$p ok" || echo "$p podmena"
done < spisok.txt

Заодно видно, доходит ли https через CONNECT: заглушки на нём валятся первыми.

утащила скрипт, спасибо

Добавлю замер, которого нет почти нигде: поведение под параллелью. Чекер ходит по строке в один поток, получает полсекунды и ставит галочку. Прогон открывает через ту же строку двести соединений, и отклик уезжает на пять секунд.

Проверяется грубо: тот же эталон, но в тридцать потоков подряд, и смотрите, во сколько раз просела медиана. Просадка вдвое нормальна, просадка вдесятеро означает, что строка держит поштучные обращения и рассыпается на потоке.

Ещё смотрю, кто разбирает имена. Если разбор имени идёт на вашей стороне, вы платите за него временем на каждом запросе, и в списке это выглядит как ровная надбавка в тридцать миллисекунд.

rawsocket, про надбавку в точку. У меня после переноса разбора имён на удалённую сторону медиана упала на четверть, и это без единой правки в самом прогоне.

Переписал чекер за вечер. Теперь на каждую строку десять обращений, эталон с контрольной суммой, отдельный проход в тридцать потоков.

Из семисот строк по галочкам жили все семьсот. По новым замерам в боевую годность прошло около шестисот сорока, остальные валятся либо на CONNECT, либо на параллели.

Вот так это выглядит наглядно, если разложить отсев по причинам.

okhotnik, добавь ещё сравнение заголовков. Гоняешь запрос напрямую и через строку на свою же страничку, складываешь оба набора заголовков и смотришь разницу глазами.

Один раз находишь лишнее поле, дальше проверяешь его автоматом и спишь спокойно. Замер копеечный, а понимания даёт больше, чем весь остальной чекер.

записала себе весь список замеров, буду гонять

Гоняю неделю по новой схеме. Прогоны стали ровнее, догоны почти исчезли, потому что в работу уходят только строки, прошедшие параллель.

Спасибо, особенно за keep-alive и за заголовки, до этого сам бы не додумался.