На задаче с 6.8 процента положительных примеров любой порог дал accuracy в пределах 0.8 пункта, пока полнота падала с 19.6 процента до 0.6. Ответ никогда на всё подряд даёт 93.2. Матрица ошибок различает эти модели мгновенно, а одно число не различает их вообще.
Я объявил одну функцию дважды и померил две копии друг против друга. На одной паре раундов одинаковый код показал победу в 32.9 процента, 10.6 процента пар выдают победителя с разрывом больше 5 процентов, а самый первый раунд идёт в 3.57 раза медленнее установившейся медианы. Всё, что на этой машине меньше 3 процентов, это не результат.
Закон Бенфорда продают как экран: наводишь на столбец чисел и подделка видна. Я навёл его на 4 столбца из одного репозитория, где подделывать было некому и незачем. 3 из них провалились. Хуже того, два принятых теста дают на одних и тех же данных противоположные вердикты: столбец, который пропускает MAD, отвергает chi square.
Я собирался померить, как повторы валят сервис под нагрузкой. Трафик они действительно утраивают, в моём стенде в 2.88 раза, но обвал устроили не они. Обвал был уже на 1.2 потолка, потому что очередь стала глубже клиентского таймаута и сервер весь день доделывал запросы, которых уже никто не ждал.
Я говорил, что запрос без таймаута ждёт вечно. Половина этого неверна. Таймаут на установку соединения ядро выдаёт независимо от того, просили его или нет. На этой машине он срабатывает через 135.3 секунды. Вторая половина хуже, чем вечность: как только соединение поднялось, не считает вообще никто.
Счётчик в фиксированном окне пропускает двойную норму на границе. Это известный изъян, которому нужен тот, кто знает, где граница. Токен-бакет, на который я из-за этого перешёл, пропустил 199 за одно окно на обычном ровном потоке. Единственный, кто удержал лимит во всех 4 формах трафика, это журнал отметок, а стоит он в 50 раз больше памяти.
Одна вставка в начало порядка привела к тому, что вторая страница началась с последней строки первой. Оба запроса верные. Ещё листание через OFFSET на глубине читает 900020 строк, чтобы вернуть 20, и тратит 69.5 миллисекунды против 1.5 у той же страницы по ключу. План запроса говорит об этом прямым текстом.
На сервере с 4 ядрами я получил load average 8.19 при процессоре на 99 процентов и load average 8.10 при процессоре, который работает 36 процентов времени, и 7 процессах, застрявших на диске. Одна и та же тревога, противоположное лечение. А после целой минуты четырёх забитых ядер минутное число всё ещё показывало 2.67.
Я обошёл граф зависимостей 6 пакетов такими, какими их записал реестр на сегодня. Grunt приносит 51 пакет, написанный 32 людьми. Обещание про мелкие кубики буквально верно, потому что 40 пакетов из 67 не зависят вообще ни от чего, но у 56 из тех же 67 ровно один сопровождающий, а 3 имени держат 26 пакетов.
Я прочитал все зоны базы за 2011 год и уточнил каждый скачок до минуты. 336 скачков из 344 это привычный час. Остальные 8 это 30 минут, 2 часа, 3 часа и дважды по 1440 минут: 30 декабря, через 9 дней, две зоны теряют целые сутки. А 26 зон закончат год на час дальше от того места, с которого начали.
Шестнадцать байт против восьми это плюс 40 процентов к индексу. Порядок поступления добавляет сверху ещё 23 процента и трёхкратное время вставки, когда индекс перестаёт помещаться в shared_buffers.
Пять вызовов пламбинга дают коммит, который читает git log. Одиннадцать ревизий файла в 1703 строки стоят 187576 байт свободными объектами против 16490 в пакете. Базой дельты оказывается самая новая версия файла.