500 готово, ещё 3000 на подходе!

Решили мы немного доработать алгоритм предварительного обнаружения опасных стикеров. На какой основе?

Довольно часто встречаются целые сборники NSFW-материалов, которые именуются в формате (?<name>.+)_?\d{1,3}. Если мы обнаружили один стикер из такой «коллекции», почему бы не найти сразу все остальные? Это позволит системе заранее обработать их и при отправке выдавать ответ за считаные миллисекунды.

Алгоритм написан, запущен, и... Стражник за день изучил более 3000 стикер-паков по лолофд, а я молчу ещё за другие фд.

Причём большинство из них имели названия Lololowka\d{1,3} и Lololoshka\d{1,3}. Искали запрещённые материалы, а нашли тысячи паков по ФД. И вроде бы хорошо, но как владельцу канала @LoloSticker… больно.

Мораль басни
Алгоритм может быть мощным, но всегда нужно учитывать легитимную полезную нагрузку. И её может быть очень много. 😆

Помните эту историю? Ждали продолжение? А вот и оно.

Как я ускорил обработку файлов во много раз

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

Чтобы понять, что изменилось, давайте рассмотрим старый алгоритм:

1️⃣ Воркер подключается к серверу по WebSocket и авторизуется под своим токеном. (Это защищает файлы от кражи и позволяет учитывать бонусы модераторов.)
2️⃣ После успешной авторизации воркер запрашивает задачу. Если задач нет, он ждёт 1 минуту и повторяет запрос. Если задача есть, сервер загружает файл из Telegram и отдаёт его воркеру.
3️⃣ Воркер обрабатывает файл, классифицирует его по таблице NSFW и отправляет результат на сервер. Контроллер проверяет данные и начисляет бонусы.

Где была проблема?

Задачи скачивались в момент запроса воркера. А воркеров много! Для каждого приходилось делать запрос к базе и загружать файл с Telegram.
Итог: CPU и Load Average в сотку, а обработка одного файла занимала 30-40 секунд.

Как я решил проблему?

🔥 Батчинг работы с БД – вместо тысячи мелких запросов теперь запрашиваю большой пул задач, которые потом раздаются воркерам.
🔥 Предварительная загрузка – заранее подкачиваю файлы в балансирующий буфер, чтобы воркеры не ждали.
🔥 Отдельный сервер – вынес контроллер загрузки на отдельную машину, разгрузив БД и основной сервер.
🔥 Параллельная загрузка – Telegram иногда «тупит» и держит запрос по 5-20 секунд, поэтому теперь одновременно отправляется 25 запросов.

Результаты оптимизации:

23:03
Files in queue: 1 922 795
Buffer: 500/1000 (50.0%) | Workers: 10
Я: Написал реле, щас постестим
Я: Попробуй поменять адрес сервера у воркеров на [REDACTED]
Я: Не сказать что буффер там успевает накачиваться, но хоть пытается
Я: Уже 500(прим. автора - имеется в виду количество файлов) в кеше

23:18
Files in queue: 1 907 795
Buffer: 401/1000 (40.1%) | Workers: 27
Модератор: 1к за 2 минут (прим. автора - модератор имеет в виду что его воркеры обработали 1к файлов за 2 минуты)
Я: *****
Я: БУФФЕР СТАЛ РАСТИ

Тут координатор нашёл баланс и начал накапливать файлы для отдачи воркерам, позволяя выдавать им задачи за минимальный срок.

23:22
Files in queue: 1903795
Buffer: 908/1000 (90.8%) | Workers: 27
Я: Щас как понимаю основная статья ожидания, сетевые расходы?
Модератор: Уже нет, ты отдаёшь и принимаешь стикеры в среднем за 0.3 секунд
Модератор: Поздравляю Илья, ты смог оптимизировать это настолько что теперь мой процессор забит на 100 процентов)
Я: ***** ТЫ ТАМ РАЗОГНАЛСЯ
Модератор: СКОЛЬКО
Модератор: Я подрубил вторую видюху, пришлось немного переписать твой код, сейчас смотрю насколько поможет
Я: Я увидел 38 воркеров онлайн Щас 31

Тут мы перешли в наблюдение, будет ли оно дальше жить и на что нам надеятся.

23:43
Files in queue: 1887243

00:18
Files in queue: 1854381

Верно очередь шла вниз, но мне хотелось быстрее, поэтому я начал эксперименты.

00:30
Files in queue: 1 843 115
Я: @(тег модератора) ты механизм переподключения не убирал?
Модератор: Нет, А что
Я: ага, хочу чуть обновить реле инфографикой
Я: в момент рестартнется скоро
Модератор: Окей

Но обновил я его не только инфографикой, но и другим балансом настроек скачивания, что по моей теории должно было ускорить работу...

А вот и последний пост из серии про проверку стикеров.

1:11 Files in queue: 1808521
Buffer: 4768/5000 (95.3%) | Workers: 32
Я: Кеш ещё греется
Я: 10 файлов в секунду пока в пике
Я: 12 файлов в секунду пик
Я: Немного поменял настройки буфферизатора, разогнались, уже 1к в буфферe
Я: Download speed 28.32 files/sec
Я: СКОРОСТЬ ЗАГРУЗКИ ФАЙЛОВ ВДВОЕ ВЫШЕ СКОРОСТИ РАБОТЫ ВСЕХ ВОРКЕРОВ
Я: ОН ПЕРЕПОЛНИЛСЯ
Модератор: АХХАХАХВХАХВХА

Мы достигли предела совершенства контроллера, он работал с файлами так быстро и эффективно, что успевал попутно отдохнуть и собрать буффер.

1:47 Files in queue: 1775747
Buffer: 4779/5000 (95.5%) | Workers: 32

5:03 Files in queue: 1597441
Buffer: 4850/5000 (97%) | Workers: 36

И наконец... 4 марта, 5:35:40 - мы разобрали 2 миллиона, всего 1 день, 9 часов и 33 минуты. Получается мы в среднем обрабатывали 16,5 файлов в секунду. (по факту в пиках куда быстрее).
Ну а так как постик получился короче, то я подкрепил вам видео того как шла эта обработка от лица контроллера

Что же... Раз уж у канала стоит метка "Авторский канал", то я опять воспользуюсь правом поговорить о... важном :D
Как немногие могли заметить, последние 24 часа я пропал из сети, статус онлайна обновлялся дай бог раз в 4 часа, но на сообщения особо не отвечал. Бустеры всё знали, теперь время раскрыть тайну и другим. Всё просто, я на сутки гонял на поиск в соседней области, а как оказалось, со связью там вообще беды. Ну и я, после того как довольно долго не мог нормально посетить лесные поиски и помогал только на городских, с радостью искал в лесу, а болото которое я проходил в своих болотоходах, м-м-м... Короче да, выбрался из города и отдыхал от него.
Ну и я не мог не поделиться с вами некоторыми фотографиями и видосиками с этого приключения.
(больше в комментариях)

@Nord_in, лови билд, я исправил баг с улетающей в космос Лайей