Клиентская оптимизация *

Расскажу, как и почему я в какой-то момент решил написать собственный pivot grid — без сторонних библиотек, на чистом JavaScript и DOM. И что из этого получилось: от первой версии с обычным GROUP BY до кэширования больших выборок и цепочки связанных гридов.

Наш сетевой драйвер терял пакеты. Не время от времени, а постоянно. На пропускной способности линии с 64-байтными пакетами мы теряли 31% всего трафика.

В качестве оборудования использовался Ethernet-контроллер на 1 Гбит/с на SoC RISC-V. В спецификациях говорилось, что он может справляться со скоростью проводного трафика. Движок DMA работал корректно. Обработчик прерываний срабатывал вовремя. Тем не менее, пакеты исчезали.

Я начал с очевидного подозреваемого: очереди получения. Реализация выглядела вполне логично — простой связанный список с указателями на голову и хвост. Под нагрузкой (64-байтные пакеты на пропускной способности линии) драйвер терял 31% пакетов! При профилировании обнаружилась причина проблемы: производительность убивали связанный список и спин-блокировки.

Я переписал драйвер, использовав кольцевой буфер без блокировок. Результаты: потеря 31% пакетов превратилась в 0,12% — улучшение в 258 раз!

В этой главе мы поговорим о структуре очередей для драйверов устройств.

Наш загрузчик оказался слишком медленным. Требование было чётким: загружаться менее чем за 500 миллисекунд. Показатели оставались не менее чёткими: 720 миллисекунд. Мы отставали от нужного значения на 44%.

Это требование не было «мягким». Загрузчик должен был работать в промышленном контроллере, обязанном реагировать вскоре после включения питания. Каждая секунда времени загрузки — это потерянная продуктивность. В спецификации к изделию был указан максимум в 500 мс. Мы обязаны были их обеспечить.

Задача загрузчика была простой:

1. Инициализировать оборудование (UART, SPI, DDR-контроллер)

2. Загрузить ядро из флэш-памяти

3. Спарсить дерево устройств

4. Перейти ко точке входа ядра

Реализация казалась логичной: стандартные структуры данных из библиотеки C. Проблема выявилась при профилировании: 45% времени загрузки тратилось на malloc/free! В загрузчике всего с 64 КБ ОЗУ динамическое распределение роняло производительность.

Наш веб-краулер потреблял 128 МБ ОЗУ только на отслеживание посещённых URL. На встраиваемом устройстве с 256 МБ это была половина всей памяти.

Задача краулера была простой: отслеживать посещённые URL, чтобы не краулить одну и ту же страницу дважды. После обработки 1 миллиона URL (средняя длина 80 байт) хэш-таблица, в которой хранились эти URL, разрослась до 96 МБ плюс оверхед.

«Можем ли мы обменять точность на память? Нас вполне устроит несколько дублированных операций, если это позволит сэкономить большой объём памяти», — сказал мне мой менеджер во время ревью кода.

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

В пайплайне перевода видео в Яндекс Браузере скорость работы в синтезе речи долго оставалась узким местом: одно видео — это сотни фраз, каждая генерируется отдельно, и любая сэкономленная миллисекунда становится заметной в масштабах сервиса. 

Внутри TTS работает каскад из трёх компонентов: языковая модель предсказывает аудиотокены по тексту, диффузионный декодер восстанавливает мел‑спектрограмму из латентов, а вокодер превращает её в звуковую волну. Долгое время самой тяжёлой была языковая модель, но после её оптимизации на первый план вышел декодер латентов — его forward pass запускается на каждом шаге семплинга диффузии, а шагов — десятки. Именно его мы и взялись ускорять.

Когда маркетологи хотят всё: сырые данные в GA4, запись сессий в Метрике, хитмапы в Clarity и при этом «Lighthouse 100» в PageSpeed Insights — приходится изобретать. Расскажу, как мы это сделали на небольшом проекте и во что это обошлось по времени и нервам.

Проект — нишевый агрегатор российских хостинг-провайдеров. Более 120 страниц в sitemap, 31 статья, десятки категорий услуг, живые цены, сравнения. Стек: Astro 6 + Strapi 5 + Tailwind 4, плюс Partytown, PostgreSQL, Nginx и обычный VPS на Ubuntu. Сайт собирается в статику во время билда, никакого SSR в рантайме нет.

На desktop — Lighthouse 100 / 100 / 100 / 100. На mobile с жёстким throttling (4x slow CPU) — 99 / 100 / 100 / 100. В реальных условиях и по Chrome UX Report — 100 везде. LCP на desktop — 0,5 секунды, на mobile throttled — 1,7 секунды. CLS — ноль. TBT — 10 ms на мобильном и 0 ms на десктопе.

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

Такая архитектура усложняет работу с клиентским профилем. У бизнеса нет единой истории взаимодействия с гостем, менеджеры работают с фрагментами данных, а сервис, маркетинг и аналитика опираются на неполную картину. Для ресторанной сети это напрямую влияет на персонализацию, качество обслуживания, LTV и повторные визиты.

В проекте для сети из 10 ресторанов была реализована единая база данных гостей. Задача системы — собрать в одном профиле все взаимодействия клиента с бизнесом: от первого контакта и переписки до бронирований, чеков, отзывов, оплат, технических инцидентов и повторных визитов.

Сжатие текста уже давно стало стандартом в мире веб‑приложений. Сокращение объёма данных даёт сокращение времени передачи и снижение нагрузки на сетевой канал. Однако, часто настройка компрессии сводится к динамическому сжатию gzip и настройкам по умолчанию. В этой статье разберём вопрос сжатия более глубоко. Для начала вспомним основные технологии сжатия, доступные в вебе.

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

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

Когда клиентов мало, администратор может быстро их обзвонить: спросить, всё ли понравилось, и зафиксировать ответы. При масштабировании бизнеса этот вариант уже не подходит: звонки отнимают много времени. В итоге часть визитов остаётся без проверки, а бизнес узнаёт о проблеме, когда недовольный клиент опубликовал негативный отзыв в интернете, ухудшив рейтинг компании, и перестал возвращаться.

В этой статье разберём, как автоматизировать исходящие звонки. Клиенту, получившему услугу,  звонит голосовой робот и проводит короткое анкетирование. Результаты опроса сразу попадают в рабочую таблицу, а если клиент остался недоволен, управляющий дополнительно получает СМС и может быстрее разобраться в ситуации.

Стек решения: Python 3.10+, Flask, requests, python-dotenv, SQLite, YCLIENTS API, голосовой робот и SMS API МТС Exolve, MWS Tables.

Если вы думаете, что внедрение CRM — это «купить подписку, выдать доступы менеджерам и ждать роста продаж», спешим вас расстроить — такая схема устарела лет 10 назад.

Привет, Хабр! Меня зовут Наталия Меркулова, я руковожу продвижением CRM-системы и виджетами Envybox. Мы в Envybox создаём CRM-систему, которая не будет отпугивать менеджеров и забирать у них последнюю мотивацию работать. Вот уже 11 лет мы помогаем автоматизировать рутинные процессы — и, несмотря на то, что многие на рынке знают, что такое CRM, по нашему опыту мало кто понимает, когда в компании она действительно нужна. Чаще всего ценность теряется на этапе отрицания изменений командой. Поэтому сегодня хотим поделиться, почему так происходит, и как такие барьеры преодолевать, чтобы команде стало легче в том числе. В статье мы поговорим о том, как отказаться от табличек и листочков в пользу автоматизации и донести эту мысль команде.

В предыдущей статье «ЕРИП перешёл на онлайн-возвраты — что это меняет?» мы рассмотрели механизм внедрения этой функции. Сегодня фокус — на сервисе E-POS, который также стал полностью автоматизированным.

Раньше оплата в E-POS проходила быстро, а возврат денег мог затянуться на неделю. Теперь это изменилось: протоколы автоматизированных возвратов разработаны и внедрены. Разбираемся, как это работает и почему бизнесу, работающему с предоплатами, стоит обратить на это внимание.

При работе с современными CPU устранение ошибочного предсказания ветвления — ключевой способ повышения скорости программ. Один из самых эффективных способов снижения количества ошибочных предсказаний— полное устранение ветвлений.

Возьмём для примера простую задачу: итеративный обход массива и копирование всех чисел меньше 500 в новый массив. Если числа распределены случайно, то результат условия if становится непредсказуемым для блока предсказания ветвления CPU. Из-за этого показатель ошибочного предсказания будет высоким, существенно препятствуя производительности, потому что процессору многократно приходится сбрасывать конвейер и начинать исполнение повторно.

«Задача абстракции — не быть расплывчатой, а создать новый семантический уровень, на котором можно достичь абсолютной точности», — Эдсгер Дейкстра

Взрывной рост количества промахов кэша

При определении топологии сети для обхода 500 коммутаторов нашей системе требовалось 37,5 миллисекунды. Вроде бы это не так медленно, если не учитывать количество промахов кэша: 8,5 миллиона. При 500 узлах это 17 тысяч промахов на узел.

Структура данных была фундаментально неподходящей для этой задачи.

Работа инструмента была простой: определение топологии сети при помощи обхода графа соединённых устройств. У каждого коммутатора было до 48 портов, а нам нужно было при помощи поиска в ширину найти все доступные устройства из начальной точки.

Реализация была как по учебнику — список смежности со стандартным BFS. В случае сети из 500 коммутаторов (в среднем по 12 соединений у каждого) статистика была такой: 8,5 миллиона промахов кэша на 500 узлов. Это 17 тысяч промахов кэша на узел!

Я переписал этот код, реализовав графовое представление, учитывающее кэш. Результаты: код стал в 3,75 раз быстрее, а количество промахов кэша уменьшилось в 7 раз.

В этой главе мы поговорим об эффективном описании и обходе графов.

«В Computer Science есть только две сложные вещи: инвалидация кэша и придумывание названий», — Фил Карлтон

Разрыв в производительности

Наш парсер логов обрабатывал 800 тысяч строк в секунду. Нам требовалось 3 миллиона строк в секунду. От нужного нам показателя мы отставали в 3,75 раза.

Задача инструмента заключалась в парсинге строк логов в реальном времени, извлечении временных меток, уровней логов и сообщений из миллионов строк в секунду. Обработка миллиона строк логов в текущей реализации требовала 1,25 секунды — слишком долго для анализа в реальном времени.

Профилировщик показывал 85 миллионов промахов кэша. Для обработки строк это казалось слишком большим показателем.

В реализации использовались стандартные строковые функции C — простые, читаемые, но, очевидно, слишком медленные.

Я переписал этот код, добавив обработку строк с учётом кэша. Результаты были такими:

В 4,5 раза быстрее и в 7 раз меньше промахов кэша.

В этой главе мы поговорим о том, как эффективно использовать кэш при обработке строк.

Изображения играют важную роль в любом веб‑приложении. Это могут быть элементы оформления интерфейса или основной контент сайта. В любом случае, перед разработчиками и администраторами стоит задача эффективной работы с картинками и в этой статье мы рассмотрим решения, которые реализуются веб‑сервером Angie.

«Блокировки — это goto конкурентного программирования», — Морис Херлихи

Проблема 60%

Наша система логгинга тратила 60% своего времени на ожидание снятия блокировок. Не на выполнение полезной работы, только на одно ожидание.

Восемь ядер, пытавшихся записывать сообщения логов, имели общий кольцевой буфер. Реализация была простой: буфер защищался мьютексом. При высокой нагрузке, когда все ядра записывали логи одновременно, профилировщик демонстрировал ужасный паттерн: 60% тактов CPU тратилось на операции с мьютексом.

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

«Можно ли улучшить ситуацию, отказавшись от блокировок?», — спросил меня мой менеджер во время ревью производительности.

Этот вопрос привёл к полной смене архитектуры...

«Плохие программисты беспокоятся о коде. Хорошие программисты беспокоятся о структурах данных и их взаимосвязях», — Линус Торвальдс

Споры о планировщике

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

Вставлять новые задачи с приоритетом (O(log n))

Запрашивать задачу с наибольшим приоритетом (O(1))

Удалять задачу с наибольшим приоритетом (O(log n))

Кто-то предложил: «Давайте используем отсортированный массив». Но вставка будет занимать O(n) — придётся сдвигать элементы.

Кто-то ещё сказал: «Возьмём связанный список». Однако поиск наибольшего выполняется за O(n) — необходимо сканировать весь список.

Третий вспомнил о двоичном дереве поиска. Но из Главы 9 мы уже знаем, что BST ужасно ведут себя с кэшем.

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

Когда цифровой продукт выходит на международный рынок, перевод интерфейса становится одной из ключевых задач для команды разработки. Казалось бы, всё просто: передал фразы переводчикам — получил обратно тексты на нужных языках и заработал новую аудиторию в других странах. Но в реальности обеспечение качественной локализации — это настоящий квест: теряющиеся ключи, винегрет из языков на одной странице, накопление невидимого долга и многочасовая рутина, выбивающая команду из рабочего потока.

Нам казалось, что в диспетчерской Яндекс Go всё под контролем. Потом мы запустили аналитический скрипт и выяснили, что 37% интерфейса частично не переведено и пользователи за рубежом видят винегрет из родного языка и дефолтного английского.

Я Ира Туманова, разработчик интерфейсов Яндекс Go. В этой статье расскажу про эволюцию контроля переводов: от ручного труда до автоматизации жизненного цикла ключей. Вы поймёте, почему важно не только настроить работу с переводами на старте проекта, но и отслеживать её качество на всех этапах, а также узнаете, какие маленькие хитрости способны избавить команду от внезапных «переводческих завалов».

Я всю жизнь писал только бэк и подкапотщину - будь это классический КРУД, хайлоад, CLI, [вставьте свое]... И для любых сетевых взаимодействий чаще всего люди думают именно прикладными вещами - GRPC, REST, Kafka, не задумываясь об этом глубже - супер удобные инструменты с защитами от дураков и прочими радостями

Но тут спохватился я писать фронт - подключать свое же к себе же. И в этот момент я понял, насколько же это сложно, муторно и, главное, НЕУДОБНО взаимодействовать REST'ом

ЗАЧЕМ ОН НУЖЕН?? - У нас нет удобного контракта общения (eg Proto, Avro) кроме Swagger, который нужно поддерживать с обеих сторон. Да и к тому-же, сложность взаимодействия с JSONом с ОБЕИХ СТОРОН - одна постоянно маршаллит, защищается, ищет поля, в то время другая боится резких обновлений, что строчка получения поля может превратиться в что-то в роде