#highload — Public Fediverse posts

Как не растерять девятки в SLA от облачного сервиса до вашего прикладного ПО

Думаю, многие сталкивались с ситуацией, когда облачный провайдер честно обещает 99.95% или даже 99.99% SLA, но в реальности бизнес-система падает на часы. Формально облако работает, виртуалки доступны, диск жив, сеть отвечает. Фактически пользователь открывает приложение и получает ошибку. Самый неприятный момент заключается в том, что в такие минуты невозможно показать пальцем на провайдера и сказать «проблема на стороне облака», потому что технически облако действительно работает, а вот система нет. Точнее работает, но не как единое целое. Я намеренно не погружаюсь сильно в техническую реализацию того или иного описанного метода по улучшению отказоустойчивости. Сейчас эту задачу прекрасно решает почти любая LLM. Цель статьи – поделиться своим майндсетом: на какие вещи я обращаю внимание, когда передо мной стоит задача улучшить стабильность highload-сервиса.

https://habr.com/ru/companies/cloud_ru/articles/1067910/

#sre #highload #sla #kafka #kubernetes

От 12 часов к 30 минутам: как мы join’им миллиарды товарных движений в ClickHouse

Всем привет! Меня зовут Муса. Наша команда занимается витринами данных по товарному учёту. Каждый день мы доставляем около 10 млрд записей в разных форматах. На этих данных строится различная аналитика, связанная с товарными запасами и движениями экземпляров. Перед нами встала задача: пять раз в день обогащать выгрузку из миллиардов экземплярных остатков дополнительными атрибутами для построения различного рода аналитики. История этих атрибутов уже измерялась десятками миллиардов записей. Первое решение выглядело просто: положить данные в ClickHouse и сделать JOIN. Но одна выгрузка считалась около 12 часов, а нам нужно было укладываться в десятки минут. В статье расскажу, про то, как мы смогли сократить время обработки примерно до 33 минут, про ключевой подход при работе с большими объёмами данных, а также попытаюсь донести важность локальности данных на примере реальной задачи.

https://habr.com/ru/companies/ozontech/articles/1064182/

#highload #clickhouse #backend #systemdesign #bigdata #базы_данны #sql #olap #архитектура_данных #ozon_tech

Как я придумывал замену Redis и что из этого получилось

Некоторое время назад мне пришла задача спроектировать высокопроизводительный балансировщик нагрузки для протокола Diameter. Через 3 месяца задача исчезла, так как как оказалось слишком долго и дорого, но в итоге балансировщик был сделан и имеется его MVP которое готово к установке как на реальное железо так и в облаке. В итоге продукт получился неплохим, и он с лихвой выигрывал имееющееся решение в той компании, по производительности был выигрыш раз в 6 по ресурсам раз в 100. Но суть не в этом, а в том что балансировщик был кластерным и умел хранить сессии в Redis. Решение было сделано, оно показало работоспособность, все хорошо, но меня не устраивала производительность. В тот момент я столкнулся с очень интересной проблемой - по каким то причинам я не мог пробить барьер в 5-7К Diameter Transactions per second. В принципе 5-7К TPS было неплохо, но проблемным участком как показал анализ был Redis. Проведя немного времени я смог добиться приемлемого результать и производительность поднялась до 20К TPS но там были другие проблемы.

https://habr.com/ru/articles/1067130/

#c++ #redis #grpc #protobuf #inmemory_database #highload #keyvalue #cache #latency #redisdb

Балансировка кластера NGFW: 5 особенностей, которые важно учитывать при построении высокопроизводительной инфраструктуры

На первый взгляд балансировка кластера NGFW мало отличается от балансировки других средств информационной безопасности или ИТ-сервисов. Однако на практике такая архитектура имеет ряд особенностей, которые необходимо учитывать уже на этапе проектирования. В статье разберем пять ключевых особенностей построения высокопроизводительного кластера NGFW: от работы балансировщика на уровне L2 и обеспечения симметричной обработки сетевых сессий до резервирования компонентов решения и контроля состояния кластера.

https://habr.com/ru/companies/dsol/articles/1065008/

#масштабирование #отказоустойчивость #отказоустойчивый_кластер #highload #high_availability #балансировка_нагрузки #высокая_производительность #ds_proxima #балансировщик_нагрузки

Как мы сделали протобаф-адаптер CONTRACT быстрее libprotobuf

CONTRACT умеет писать protobuf-совместимый wire-формат — и в 20 из 28 замеров обогнал по скорости настоящий libprotobuf, включая его собственный сгенерированный protoc-код. Разбираем три инженерных решения, которые это дали, и два сценария, где не получилось. CONTRACT — это C++ библиотека сериализации без кодогена и рантайм-рефлексии: схема объявляется один раз, в самой C+±структуре, и работает сразу под разные форматы.

https://habr.com/ru/articles/1064148/

#с++20 #с++ #protobuf #highload #serialization #adapters

Оптимизация Angie для высоких нагрузок

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

https://habr.com/ru/articles/1062790/

#angie #оптимизация #ускорение #highload

Когда 1С выдерживает тесты, но падает в проде: как проверить систему под реальной нагрузкой

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

https://habr.com/ru/companies/infostart/articles/1063416/

#1С #нагрузочное_тестирование #HighLoad #производительность_1С #JMeter #корпоративные_системы #тестирование_производительности #WebSocket #масштабирование

Как VPS с 1 ГБ RAM пережил 1,2 млн запросов за сутки: разбираю «Шакализатор» по слоям

Мой мемный сервис «Шакализатор» победил в премии Яндекс Практикума , но меня больше интересовал другой вопрос: как VPS с одним ядром и 1 ГБ RAM пережил 1,2 млн запросов за сутки? Серверную часть в основном писал Codex, а я во время наплыва обновлял статистику и ждал падения. Теперь разбираю код, логи и серверные срезы: что именно спасло систему, где нам просто повезло и почему миллион запросов оказался не тем, чем кажется. Почему он не упал

https://habr.com/ru/articles/1061220/

#Nodejs #Nextjs #Nginx #VPS #highload #кэширование #ограничение_конкурентности #graceful_degradation #Codex #swap

Go без мифов: переход с C++, highload, рынок, зарплаты и путь разработчика — интервью с Владимиром Балуном

Go часто называют простым языком. Но простота синтаксиса не отменяет конкурентности, рантайма, сборщика мусора, интерфейсов, особенностей памяти и реального production-опыта. Я, Александр, автор телеграм-канала « Shulepov Code », поговорил с Владимиром Балуном — разработчиком на C++ и Go, автором YouTube-канала « Владимир Балун » о программировании и основателем школы программирования. В этом выпуске мы разбираем, почему Go стал таким востребованным, кому он подходит, как на него переходить, а также сильные и слабые стороны языка. Обсуждаем реальные проекты, особенности конкурентности, память, сборку мусора и production-опыт.

https://habr.com/ru/articles/1059838/

#Go #Golang #C++ #highload #горутины #Observability #backend #микросервисы #карьера_разработчика #переход_на_Go

Как мы делали три консоли для киберигры: опыт разработки новой версии тренажера

Привет! На связи команда Далее . В этой статье расскажем, как мы взяли довольно простую игру-тренажер по кибербезопасности и сделали ее самостоятельным продуктом с тремя отдельными консолями, редактором сценариев, ботами для их проверки и аудиочатом на WebRTC.

https://habr.com/ru/companies/dalee_group/articles/1059524/

#кибербез #информационная_безопасность #консоли #golang #webrtc #centrifugo #highload #разработка_игр #вебразработка #архитектура

Почему JSON на практике — быстрый формат для баз данных (если выкинуть лишние абстракции)

Мы привыкли считать JSON «медленным» текстовым форматом, удобным исключительно для людей. Мы используем его для REST API, конфигурационных файлов и веб-интерфейсов, но как только речь заходит о высоконагруженных базах данных, мы сразу же смотрим в сторону Protocol Buffers, FlatBuffers или проприетарных бинарных форматов. Но что, если взглянуть на JSON не с человеческой стороны, а со стороны машины? Если убрать тяжелые слои абстракций (такие как рефлексия Go и сетевые оверхеды), стандартный JSON оказывается удивительно плотным, прозрачным и невероятно быстрым в обработке. На его основе можно построить встраиваемый Key-Value движок, который выполняет чтение за 16 наносекунд , а поиск — менее чем за 0.5 миллисекунды на базе в миллион записей. Погрузиться в наносекунды и код

https://habr.com/ru/articles/1056718/

#go #makodb #shared_memory #highload #json #zero_allocation #оптимизация #базы_данных #системное_программирование #асинхронность

От полной выгрузки к S3 и PostgreSQL: как мы доставляем гигабайты данных в память подов

Представьте себе высоконагруженный сервис, который решает, с какого из множества складов нужно отправить товар покупателю. В пике через него проходит около 600 000 RPS , а строгий SLA требует ответа в пределах 50 мс. Для расчёта нужно за минимальное время выбрать оптимальный склад с учётом остатков, доступности и других данных, которые хранятся в разных микросервисах и их базах данных. Первое, что приходит на ум, — обратиться к этим сервисам по API во время запроса и получить всё необходимое для расчёта. Но один запрос может затрагивать сотни и даже тысячи складов, не считая связанных сущностей. Такое число сетевых вызовов быстро превысит SLA и приведёт к клиентским таймаутам. Сетевые запросы к мастер-системам в нашем случае — непозволительная роскошь, поэтому мы вынуждены держать слепок данных прямо в памяти подов. А значит, появляется новая проблема: как быстро и надёжно доставлять постоянно меняющиеся данные из мастер-систем в оперативную память сотен подов.

https://habr.com/ru/companies/ozontech/articles/1052132/

#highload #backend #golang #go #проектирование_систем #программирование #высоконагруженные_системы #ozon_tech

И снова самый быстрый парсер JSON. Очередной

За свои 17+ лет в активной разработке я встречал много проблем, но одна преследовала меня постоянно: JSON. Нет, с самим форматом все ок, но вот с его чтением — не все норм. Когда я только начинал работать с PHP, я списывал это на скриптовость языка. Отчасти из‑за этого я даже поменял стек. Но когда приходили по‑настоящему большие файлы, это всегда было больно. Иногда — очень. Был проект, где мы ждали не обработку информации бизнес‑логикой, а банального парсинга. Файлы доходили до десятков гигабайт и не всегда влезали в оперативку. Тогда я и заработал себе персональный todo — разобраться с этим раз и навсегда. Сейчас, находясь в поиске новых возможностей, я решил вспомнить эту старую боль. Я уже давно не PHP‑разработчик, но проблема в индустрии всё та же. Объемы данных растут, требования тоже, а воз и ныне там. Нет, есть море крутых решений. Даже тут, на Хабре. Но для меня всё не то. Мне нужно решение, а не костыль. То есть: никакой кодогенерации и никаких JIT (я не противник JIT, просто не хочу тянуть эту сложность). Я ступил на тонкий лед: в Go есть классная штука — пакет unsafe . Почему классная? Потому что она позволяет обойти тяжелые ненужные проверки. Плюс побитовые операции для ускорения всего, до чего только смогли дотянуться руки. Пока изучал чужие парсеры, столкнулся с обманом в репозиториях, подкручиванием статистики (куда же без него?) и перекладыванием ответственности (и аллокаций) на сторону разработчиков. Заглянуть под капот

https://habr.com/ru/articles/1053528/

#go #golang #json #zeroallocation #zerocopy #simd #avx2 #highload #unsafe #парсинг

Проектирование веб-краулера. Как решать System Design?

Привет! Продолжаю разбирать классические задачи с System Design интервью на стримах (за анонсами можете следить тут ), а это текстовая версия стрима. В прошлый раз была бесконечная лента, сегодня очередная классика жанра - веб-краулер. Условие звучит примерно так:

https://habr.com/ru/articles/1049912/

#system_design #сис_диз #Собеседование #Проектирование #highload #задачи #задачи_для_собеседований #middle #senior #web_crawler

PostgreSQL не тормозит. Почему мы перестали масштабировать базу данных и начали масштабировать архитектуру

Каждый раз, когда в компании возникают проблемы с производительностью PostgreSQL, обсуждение обычно идет по одному и тому же сценарию. Сначала DBA оптимизируют запросы. Потом появляются новые индексы. Потом увеличивается размер серверов. Затем появляются реплики. Потом еще реплики. И через некоторое время выясняется, что значительная часть бюджета на инфраструктуру уходит на обслуживание системы, которая изначально должна была просто хранить данные. Недавно мы в Tarantool столкнулись именно с такой ситуацией у одного из клиентов. В этой статье расскажем подробно об этой ситуации, поделимся, как мы ее решили и почему такой подход в целом стоит использовать практически всем, кто имеет дело с PostgreSQL.

https://habr.com/ru/companies/vktech/articles/1048164/

#postgresql #производительность #масштабирование #tarantool #cdc #витрина_данных #архитектура #highload #чтение_против_записи #vk_tech

# pg-smart-search: Путь от 8 секунд до 40 мс — Часть 2. Масштабирование до миллиона строк и производственная архитектура

Привет, Хабр! В первой части мы разобрали архитектуру pg-smart-search изнутри: параллельный Promise.race , механизм Zombie Prevention через AbortSignal , адаптерный паттерн и CLI-инструмент. Если не читали -- рекомендую начать оттуда, здесь я буду отсылать к тем концепциям. В этой части речь пойдет о том, что происходит, когда ты запускаешь всё это на реальных данных. На объемах до 100K строк система работала именно так, как задумано: FTS побеждал в Promise.race первым, кэш давал sub-1ms на горячих запросах, пропускная способность — 90 req/sec. Картина мечты. Потом пришли данные. Много данных. 1 000 000 строк с нормальным, реальным словарем — и всё сломалось. Время поиска улетело к 8-ми секундам. В этой статье - честный разбор двух этапов спасения: сначала архитектурные фиксы, потом бой с «ошибками выжившего» в бенчмарках. И в конце — production-grade микрооптимизации, которые мы сделали в v1.4.1, вылизав каждую миллисекунду.

https://habr.com/ru/articles/1048024/

#postgres #nodejs #typescript #gist #opensourse #highload #backend

[Перевод] System Design: проектируем Rate Limiter, ограничитель запросов

В задаче проектирования Rate Limiter важны сразу несколько вещей: выбор алгоритма лимитирования, централизованное хранение состояния, работа через API Gateway и масштабирование до 1 млн запросов в секунду. В статье разберём, почему для такого сценария часто выбирают Token Bucket, как использовать Redis для хранения счётчиков и что делать, когда одного инстанса уже недостаточно.

https://habr.com/ru/articles/1044528/

#system_design #backend #highload #подготовка_к_собеседованию #распределенные_системы #архитектура #проектирование_систем #системный_дизайн #паттерны_проектирования #собеседования_задачи

Dead Letter Queue в Kafka на практике

DLQ — это просто топик. Сложное — всё, что вокруг него. Эта статья — про практическую архитектуру обработки событий из Kafka с отправкой данных во внешний REST API. Главная проблема такого сценария — нестабильность внешнего API. Он периодически деградирует по latency или начинает отвечать с ошибками, и это напрямую влияет на пропускную способность всего консьюмера.

https://habr.com/ru/articles/1045324/

#kafka #concurrency #asyncio #semaphore #finite_state_machine #dead_letter_queue #highload #api

2 + 2 = 6 и как мы это фиксим: lost updates в Postgres

Каждый бэкенд-разработчик, который хоть раз готовился к собеседованию, слышал про аббревиатуру ACID. Какая-то часть из слышавших сможет её расшифровать. Какая-то часть из расшифровавших — объяснить, почему важен каждый из принципов, скрытых за этими четырьмя буквами. И уж точно каждый из этих замечательных разработчиков знает цену букве «I» — isolation, изоляции транзакций. Те, кого заинтересовал заголовок, скорее всего, относятся к одной из трех категорий читателей: Первые знакомы с этими понятиями в теории, но не имели шанса решать их на практике. Вам — обещание: когда вы столкнётесь с этими загадочными на первый взгляд явлениями в бою, вы уже будете к ним готовы. А если прочитаете статью до конца и вникнете во все примеры — сможете блеснуть на собеседовании знанием тонкостей борьбы с гонками в реальных highload-приложениях, даже не имея такой практики. Вторые решали такие проблемы «на ощупь», не до конца понимая механику. Вам — собрать разрозненный опыт в систему: увидеть полную карту способов и понять, какой из них и почему обходится дороже. Третьи сталкивались с этими проблемами и знают, как их решать. Вам — наглядная демонстрация цены тех решений, которые вам уже приходилось имплементировать: конкретные цифры, во сколько на самом деле обходится каждый подход. В этом материале систематизируем способы бороться с race conditions в Postgres и считаем, во сколько обходится каждый.

https://habr.com/ru/articles/1044190/

#postgresql #postgres #race_conditions #isolation_levels #продакшен #highload

Динамические квоты и лимиты: как не завалить очередь в highload

Представьте: ваш сервис Y генерирует 10 000 событий в секунду, а сервис X может проглотить только 500. И при этом нельзя потерять ни одного события, а порядок обработки обязан быть строгим. Очередь? Конечно. Но какую? И что делать, когда она переполнится? В статье — разбираем реальную архитектурную задачу с разбором типовых ошибок, двух подходов к порядку (strict FIFO и per‑key ordering), нюансами DLQ, backpressure, идемпотентностью и скрытыми проблемами типа head‑of‑line blocking. Разобрать задачу

https://habr.com/ru/companies/otus/articles/1031282/

#highload #очереди_сообщений #kafka #backpressure #динамические_квоты #системный_анализ #архитектура_highload

Реальный time series агрегатор: как обрабатывать 10 событий/сек на графе из 300k узлов

Представьте, что у вас есть многослойный пайплайн обработки данных. Ширина слоя — 5000 узлов. Количество слоёв — 60. Общее число узлов — 300 000. Каждую секунду приходит 10 новых событий (изменений на входе). Наивный подход — пересчитать всё с нуля — будет перебирать все 300 000 узлов на каждое обновление. При 10 обновлениях в секунду это 3 млн вычислений узлов в секунду. А если ширина слоя 100 000 и слоёв 100? Получаем 10 млн узлов на пересчёт. Компьютер не справляется.

https://habr.com/ru/articles/1040918/

#NET #C# #Highload #аналитика #стриминг

Архитектура AI-сервисов: почему монолит убивает latency и GPU

Ваш AI‑чат или автокомплит тормозит при 50 запросах в секунду? Монолит убивает GPU и латенси? В этом туториале — реальная архитектура low‑latency инференса на high‑load: почему изолированный inference‑bundle вместо монолита, как выбрать между vLLM и SGLang без маркетинга, зачем нужны continuous batching и admission control. Читать разбор

https://habr.com/ru/companies/otus/articles/1031286/

#AIсервисы #LLM #инференс #highload #latency #GPU #vLLM #SGLang #continuous_batching #admission_control

Пул объектов: паттерн эффективного управления памятью

Современные аллокаторы общего назначения умеют оптимизировать выделение памяти для небольших объектов и не только, но зачастую они не дают строгих гарантий отсутствия системных вызовов при очередной аллокации или освобождении памяти. Для высоконагруженных систем, чтобы эффективно выделять и освобождать память под объекты без лишних вызовов malloc/free и потенциальных системных вызовов, используют паттерн пулов объектов.

https://habr.com/ru/articles/1035874/

#highload #аллокатор #аллокация_памяти

[Перевод] System Design: проектируем Dropbox, сервис для хранения и обмена файлами

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

https://habr.com/ru/articles/1032184/

#system_design #backend #highload #подготовка_к_собеседованию #распределенные_системы #архитектура #проектирование_систем #системный_дизайн #паттерны_проектирования #собеседования_задачи

Девять испытаний роста нагрузки: от стартапа к приложению для 25 миллионов пользователей

Эта статья совсем не технический анализ, а увлекательный рассказ о том, как маленький, но очень перспективный стартап стал топовым приложением, а также о том, какие сложности встали на пути команды разработки, DevOps и тестирования X5 Tech. Мы сразу заложили основные принципы нагруженного приложения: микросервисы как основа всего, полное покрытие метриками, асинхронность, кэширование на максималках. Какую-то функциональность разрабатывали сами, где-то задействовали сервисы других техкоманд из X5, а где-то и сторонние решения с рынка. Весь код писали на Python, использовали FastAPI и другие популярные на тот момент фреймворки и технологии.

https://habr.com/ru/companies/X5Tech/articles/1029410/

#highload #микросервисы #latency #postgresql #elasticsearch #kubernetes #hpa #балансировка_нагрузки #нагрузочное_тестирование #observability

[Перевод] System Design: проектируем сервис быстрых знакомств

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

https://habr.com/ru/articles/1026316/

#system_design #backend #highload #подготовка_к_собеседованию #распределенные_системы #архитектура #проектирование_систем #системный_дизайн #паттерн_проектирования #собеседования_задачи

От MVP на Whisper до собственной ASR: как мы построили платформу субтитров для RUTUBE

Автоматическое создание субтитров для пользовательского контента может выглядеть довольно простой задачей: берем готовую ASR‑модель, распознаем аудио из видео и сохраняем результат. Именно таким и был наш первый MVP в RUTUBE — сервис на базе Whisper, который позволил быстро проверить гипотезу и запустить субтитры в production. Но очень быстро стало понятно, что между «распознать речь» и «сделать субтитры для всего контента» лежит огромный пласт работы. Миллионы новых видео, ролики длиной до 24 часов, неизвестный язык, шумный пользовательский контент, требования к качеству текста и жесткие ограничения по скорости обработки — всё это превратило задачу из простого ASR в полноценную платформу с микросервисной архитектурой и собственной системой распознавания речи. В статье расскажу, почему Whisper не подошел для production, как мы перестроили всю архитектуру и за счет чего смогли выйти на производительность около 1200 видео в час на один ASR.

https://habr.com/ru/companies/habr_rutube/articles/1028476/

#asr #whisper #распознавание_речи #highload #субтитры #production_ml #machine_learning

Fast Atomic Flow: PHP 8.4, Swoole, NATS, Go и Закон Табуна

Как переезд в деревню, рефакторинг жизни и парное программирование с DeepSeek привели к созданию демо на Swoole, NATS и Go. Без купюр и без пони. 🐎 В галоп!

https://habr.com/ru/articles/1028346/

#php #swoole #nats #go #highload #websocket #semaphores #async #open_source #kbl

Нагрузочное тестирование с Apache JMeter: Best Practices

Apache JMeter — не просто инструмент. В этой статье разберем, как получать от него реальную пользу. Вы узнаете, почему 80% отчётов о нагрузке бесполезны, как настроить распределённый тест и анализировать не среднее значение, а процентили. Полный гайд от первого HTTPS-скрипта до информативного HTML-отчёта и Best Practices.

https://habr.com/ru/companies/otus/articles/1022194/

#java #Нагрузочное_тестирование #Apache_JMeter #Тестирование_производительности #Highload #devops #Best_Practices #Performance_Testing

Ой, готовлюсь к переносу своего маленького #highload на #rubyonrails с >120к запросов в сутки на #orangePi5. Страшно, но если что, верну обратно на обычный скучный дедик в #hetzner

Акция солидарности с Twitter от mastodon.social.

#Twitter #Mastodon #fun #highload #log #pic