Серверная оптимизация *

Это первая часть цикла статей о разработке системы публикации структурированных интерактивных постов через Telegram Bot API. В следующих частях — архитектура, рендеринг шаблонов и управление доступом к закрытым чатам.

С чего всё начинается

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

На первый взгляд — ничего сложного. Telegram Bot API умеет отправлять текст, прикреплять медиа, рисовать inline-кнопки. Но именно в этот момент начинается то, что разработчики называют «дьявол в деталях».

На практике задача немедленно разбивается на несколько инженерных проблем, каждая из которых требует отдельного решения. И если пропустить хотя бы одну — система либо ломается при первом же граничном случае, либо создаёт такой UX, что пользователи просто не понимают, что происходит.

На днях я стряхнул пыль с небольшого пет-проекта. Это простой блог, наверняка каждый из вас хотя бы думал о таком для себя.
В 2015 году я бы просто закинул файлы по FTP на хостинг за 100 рублей. Время деплоя: 30 секунд.
В 2026 году я потратил 4 часа. Я настраивал Edge Middleware, дебажил рассинхрон HTML между клиентом и сервером (hydration mismatch) и разбирался, почему облако не хочет дружить с моей базой данных из-за долгого пробуждения функций (холодного старта).

Где мы свернули не туда?
Это колесо Сансары, которое дало новый оборот.

В позапрошлом году вышла статья https://habr.com/ru/articles/814529/ про синхронизацию позиции персонажа между клиентом и сервером в Lineage 2. После прочтения появилось желание перенести эту логику в свои сырцы от когда-то разрабатываемого сервера и, возможно, запустить его где-то для себя и старых друзей поразвлекаться. Понятное дело, что современного ПК с кучей рам, хорошим процом и nvme дисками при желании было бы за глаза даже для запуска тысяч игроков, но заниматься организацией доступа из дикого интернета на свой ПК желания не было, да и обеспечивать постоянный доступ - дело такое себе. В наличии была самая дешманная впска у хостера F с доменом, но с сильно ограниченными ресурсами: одно ядро и 512Мб рам. Мягко скажем, памяти маловато.

Наспех восстановил сырцы, актуализировал сборку под современные версии java и либ, запустил - потребление хипа примерно 400Мб на старте. Без геодаты. А с геодатой - 1200Мб.

И тут появился спортивный интерес влезть в 512Мб, да еще и с геодатой.

Результатом стал оптимизированный драйвер геодаты, зашаренный на гитхабе https://github.com/mosinnik/l2-geo, репорт о потенциальном баге в JDK и эта статья.

Я занимаюсь разработкой компиляторов, то есть, пишу программы, преобразующие программы в программы. Иногда требуется нацелиться на более высокоуровневый язык, чем, скажем, простой ассемблер, и зачастую именно в таком качестве удобно взять язык C. Генерировать C не так страшно как писать от руки — в частности, потому, что генератор умеет не попадать в ловушки, связанные с неопределённым поведением. А когда пишешь на C вручную, именно неопределённого поведения следует особенно остерегаться. Здесь я опишу некоторые паттерны, которые обнаружил сам, и которые помогают мне результативно работать.

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

Здесь рассказано, как именно Linux обрабатывает системные вызовы в архитектуре x86-64, и почему при профилировании они выглядят как дорогостоящие операции.

Привет, Хабр! В первый месяц 2026 года команда Selectel выпустила из беты сетевые диски для выделенных серверов, обновила работу с Karpenter и реализовала еще несколько полезных опций. Обо всех обновлениях читайте под катом.

Привет постоянным и не очень читателям :)

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

Ремарка! Я не против конкретных цифр и конфигураций — я против попытки выдать их за универсальный рецепт. Так что этот подход оставим для SEO-статей.

В этом же лонгриде я затрону ошибки мышления при подборе серверов на 5+ лет и сдвиги, которые произошли за последние годы (и особенно хочу поговорить про огромное влияние CXL). Я плотно работаю в этой индустрии больше 6 лет и прошел подобный цикл на практике, да и админы-старожилы рассказали много интересного о том, что было раньше.

Присаживаемся, ложимся или в какой там позе вы читаете — и начинаем.

Решил один мой коллега (не разработчик) заняться пет-проектом: создать платформу с элементами соцсети и встроенным картографическим плагином. И вот приходит этот коллега ко мне с вопросом по части фронтенда: «А как бы мне отрендерить страницы: на сервере или на клиенте?», описывая то решение, которое он уже сделал и которое в целом работает.

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

Как заставить летать список из 5000+ товаров на странице? Нативный рендер кладёт вкладку, а все базовые оптимизации уже сделаны.

Разбираем послойно: внедрение React Compiler (React 19), виртуализация через TanStack, гибридное кэширование (Redis + unstable_cache) и архитектура работы с анонимными пользователями без лишних запросов к БД. Работа над ошибками, которая ускорила проект в разы.

Вчера Ollama стала устанавливаться как версия 0.15.5

Теперь доступны новые модедели, например qwen3-coder-next.

Данная модель очень хорошо пишет код, но есть одна проблема. Для ollama есть только модели с квантизацией q4_K_M размер модели 52Гб., q8_0 размер 85Гб или платный запуск из облака. Сама модель обучена на 80 миллиардах параметров, большую часть которых составил код.

Да, в минимальной конфигурации, для локального запуска этой модели необходимо не меньше 80 Гб. видеопамяти если нужна большая скорость. Конечно можно запустить эту модель и на CPU, имея от 128 Гб. DDR5 RAM, работать будет, но очень медленно.

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

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

Доступ к серверу бесплатный, но к сожалению не вечный. Когда я закончу настройку своего RAG, я выключу этот сервер. Хотя есть слабая возможность что я привезу из Китая еще один такой же.

Адрес сервера http://demonryb.ru:8080/

Доступ к моделям возможен только после того как я подтвежу вашу регистацию.

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

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

В конце 2024 года на просторах GitHub появился проект, который заставил даже самых серьёзных системных программистов улыбнуться: scx_horoscope — планировщик задач для ядра Linux, корректирующий поведение CPU в зависимости от положения планет, фаз Луны и так называемой ретроградности. Автор, Lucas Zampieri, с иронией обыграл давний системный фольклор о зависимости работы систем «от фазы Луны», превратив мем в рабочий код, который действительно загружается в ядро и участвует в распределении процессорного времени.

За шутливой обёрткой скрывалась демонстрация куда более важного события — появления в ядре механизма, позволяющего вынести логику планирования из монолитного кода в динамически заменяемую политику. Астрология здесь лишь повод обратить внимание; суть — в том, что экспериментировать с алгоритмами распределения ресурсов теперь можно без месяцев ожидания мержа в upstream и без пересборки ядра.

Для пользователя может показаться, что переход с HTTP/2 на HTTP/3 — это просто замена TCP на UDP в конфиге. Но для серверного ПО с многопроцессной архитектурой этот шаг превращается в настоящую «головную боль». Классическая схема с accept(), на которой годами строилась работа с TCP‑соединениями, в мире QUIC попросту не существует. Пакеты летят в UDP‑порт, и ядро ОС больше не знает, какому именно рабочему процессу их отдать.

В оригинальном nginx это привело к тому, что поддержка HTTP/3 уже долгое время остается «экспериментальной» и ограниченной: она страдает от проблем с обрывами сессий и деградации сервиса при обновлении конфигурации. Для многих это стало стоп‑фактором для внедрения протокола в реальный продакшен.

В этой статье мы расскажем, как в Angie 1.11 нам удалось устранить эти фундаментальные недостатки. Мы не просто добавили поддержку протокола, а пересмотрели механику взаимодействия с ядром. Путь от простых хешей до создания полноценного аналога accept() для QUIC с помощью BPF‑программ позволил нам заявить: реализация HTTP/3 в Angie закончена, лишена «детских болезней» nginx и полностью готова к эксплуатации в высоконагруженных средах.

Добро пожаловать под капот современного транспорта данных.

Привет, Хабр! Под конец 2025 года мы в Selectel запустили отказоустойчивый изолированный DNS-сервис и новую конфигурацию для работы с большими объемами данных, представили AI-консультанта для SelectOS и реализовали много других полезных обновлений. Подробности под катом!

В этой статье я подробно опишу 5 стадий принятия неизбежного  уровней оптимизации. В качестве примера рассмотрим, как я пытался оптимизировать функцию для инструмента командной строки, который я сам и написал  I (monorepo-hash).

Примечание

Я не настаиваю на том, что изложенное здесь — 5 священных заповедей инженерии производительноcти, а также не утверждаю, что приведённые здесь приёмы точно соответствуют каким-либо «карьерным уровням». Их можно сравнить просто с вешками на пути.

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

Также отмечу, что значительную часть этого CLI я написал при подспорье ИИ-моделей. Считайте, что это лёгкий способ подмечать ошибки и находить, что можно оптимизировать.

Кликбейтный заголовок? Что ж, даже, если так — вы же открыли статью, значит, он сработал :)

Стандартный мониторинг часто пропускает «тихих убийц» — запросы, которые по отдельности кажутся нормальными, но в сумме создают аномальную нагрузку на СУБД. В итоге система живет в хрупкой идиллии до первого аврала.

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

Оптимизация кода. Что быстрее: циклы vs стрелочные функции. Простая задача с собеседования. Разбор простых итераций с примерами кода

Кейс: как использовать frontend-фичи и UX для оптимизации сетевого трафика запросов на примере Дзена и других сервисов

Проблема: когда из-за «оптимизации» код замедляется

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

Black-White Array (BWA) — это упорядоченная структура данных с амортизированным временем операций вставки/поиска/удаления и используемых участков памяти. Преимущества:

• Амортизированное время вставки/удаления/поиска сравнимое с реализацией BTree от Google;
• Низкое количество аллокаций памяти при операциях вставки - меньше давления на сборщик мусора, ниже фрагментация памяти;
• Массивы под капотом: данные лежат рядом, что улучшает кэшируемость процессором и скорость обхода/доступа к данным;
• Позволяет хранить элементы с одинаковыми ключами - не нужно использовать дополнительные структуры для группировки таких элементов;
• Низкий оверхед на хранение служебной информации - экономия памяти по сравнению с другими структурами данных;
• Удобен для вставки батчами;
• Простая сериализация и десериализация;