Выход версии 5.9.3 прошёл довольно быстро, тем не менее изменений с версии 5.8 было сделано очень много и ниже мы их опишем.
Новая обработка списков
Мы перешли на python в этой части и не жалеем по нескольким причинам:
- nosetests позволяют гораздо легче тестировать код
- код стал значительно чище
- предыдущая версия на bash становилась всё менее и менее понятной с каждой новой «фишкой»
В результате новая версия обработки сократила число адресов, добавленных в базу зря (чем меньше адресов добавлено, тем выше производительность поиска по ней).
В бонус получили более правильную логику работы с кириллицей и прочими своеобразными URL’ами.
HTTP URL-матчинг модуль
После того, как мы сделали первую версию обработки списков, остро всплыл один недостаток алгоритма матчинга URL, который раньше затыкался (не всегда удачно) на этапе обработки списков. Мы решили поступить правильно и навести в коде модуля ядра «красоту» и переработать его.
Использование cmocka
В самом начале, перед рефакторингом мы поняли, что наш старый костыль для проведения чего-то похожего на Unit-тесты модуля фильтрации (его часть можно использовать в userspace для тестов) ужасен и неудобен. Для перехода на эту замечательную либу для тестирования понадобилось всего 2-3 часа (включая хоть какую-то дружбу тестов с инструментами для разработки команды). Дальше расширить покрытие тестами было уже значительно легче, а с хорошими тестами и рефакторить код получалось куда проще.
Производительность
Если чистая производительность (без учёта влияния нагрузки на сетёвки и прохода по всему сетевому стэку) алгоритма предыдущей версии составляла около 800000 пакетов/сек на 1 ядро процессора ≈2.5-3GHz, то сейчас нам удалось выжать 1900000-2100000 пакетов.
Решение проблемы с //
Имеется такая дурацкая бага:
http://test.url/get//request
часть браузеров приводит к виду
http://test.url/get/request
а часть — нет. Эту проблему имеют многие другие DPI (провели небольшой опрос среди коллег, абсолютно все могут обходить заблокированные HTTP-URL просто добавив второй / в URL). В общем для Carbon Reductor теперь нет разницы, какое число слэшей поставлено в запросе.
В качестве бонуса — это сократило объём используемой Carbon Reductor памяти.
Чистка кода
Перед этой глобальной доработкой мы решили воспользоваться новым опытом, полученным за время разработки Carbon Reductor и привести в порядок весь код проекта. Он стал значительно понятнее и короче аж на 30%. Надеемся, что это позволит нам быстрее двигаться вперёд в будущем!
Исправления багов
Отображение заблокированных адресов в вебе
После добавления новой обработки списков, файл со всеми обработанными URL (http.load) содержит адреса в разных кодировках, из-за чего пока что имеется проблема с его отображением в вебке. В качестве временного workaround, по умолчанию теперь в списках отображается необработанный список Роскомнадзора — rkn.list.
Диагностика
Теперь диагностика проверяет 3 дополнительных источника проблем:
- неполная загрузка URL в ядро (с версии 5.9.3 — ещё и исправляет)
- старая версия веб-интерфейса (при неудачном стечении обстоятельств могла вызвать проблему со стартом самого reductor и не работала фильтрация)
- запуск более чем 1го экземпляра crond (обычно из-за того, что «pid-файлы лгут»). Автоматически это исправлять мы побоялись, но уведомление администратору придёт. В целом это довольно серьёзная ошибка, приводящая к дублированию периодических задач.
Резолв HTTPS
Значительно снижена нагрузка на CPU при запуске резолва, немного ускорена её работа (раньше полный резолв на пустой базе занимал около 1м 30с, сейчас около 55 секунд), а также немного выпрямлен код всей этой подсистемы.
Чего ждать в следующей версии
Двойной буфер для загрузки URL в ядро
Сама она уже написана, лежит в отдельной экспериментальной ветке, осталось только корректно добавить блокировки, но сейчас имеется большое число более приоритетных задач, так что в релизе появится ориентировочно в первой половине ноября.
Без блокировок вероятны (пусть и не столь сильно) kernel panic при переключении. Нам была бы очень полезна помощь в обкатке этой версии под большой нагрузкой.
Оптимизация скорости обработки списков
В версии 5.9.1 мы добились скорости около 1.3 сек для 15000 необработанных URL. К сожалению, реальный мир заставил исправлять ошибки и в 5.9.3 скорость упала почти до 8 секунд. Мы поработаем над этим.
На этом все, всем спасибо 
