Высокая производительность *

Факт: как минимум 150 человек в нашей стране интересуются RISC-V настолько, что их не пугает девятибалльный шторм. Примерно столько мы собрали в офлайне 14 марта в Москве на совместном митапе YADRO с Альянсом RISC-V. Оценили, готов ли RISC-V для мобильных устройств, а для RISC-V, в свою очередь, — высокопроизводительные библиотеки. Рассмотрели экосистему RISC-V для сценариев АСУ ТП — автоматизированных систем управления технологическим процессом. И наконец, в большой дискуссии обсудили, готова ли открытая архитектура к развитию широкой экосистемы открытого ПО в различных областях. Записи выступлений и некоторые интересные тезисы — далее в статье.

Современная разработка ПО – это почти всегда про распределенные системы. Микросервисы, облака, глобальный охват – все это стало нормой. Но за красивыми диаграммами и модными словами скрывается фундаментальная сложность. Как заставить кучу разрозненных компонентов работать вместе надежно? Как гарантировать, что данные, размазанные по сети, останутся корректными и доступными? Эта головная боль знакома любому, кто проектировал системы сложнее калькулятора, будь то в требовательном финтехе, динамичном e-commerce или где-либо еще.

И вот тут на помощь (или, скорее, для обозначения поля боя) приходят три понятия: ACID, BASE и теорема CAP. Может показаться, что это сухая теория, но игнорировать их – все равно что выходить в море без компаса и карты. Эти концепции описывают фундаментальные компромиссы, с которыми приходится иметь дело каждому архитектору. Понимание их – не гарантия успеха, но его необходимое условие. Давайте погрузимся в их суть и посмотрим, как они влияют на реальные архитектурные решения.

Переход на микросервисы – это часто как переезд из тесной, но понятной коммуналки (монолита) в огромный город с кучей отдельных квартир. Свободы больше, масштабироваться проще, команды независимы – красота! Но тут же вылезает проблема, о которую разбиваются многие корабли: как поддерживать порядок и целостность данных, когда они размазаны по десяткам этих "квартир"-сервисов со своими собственными базами данных?

Старый добрый ACID, который спасал нас в монолитах с одной большой базой, здесь уже не помощник. Пытаться натянуть на микросервисы классические распределенные транзакции с двухфазным коммитом (2PC) – это почти всегда путь к страданиям. Представьте: один сервис захватывает блокировку, ждет подтверждения от другого, тот ждет третьего... Чуть что не так – вся цепочка висит, пользователи ждут, система тормозит, доступность падает. Звучит знакомо? Именно поэтому умные люди придумали альтернативу – паттерн, известный как Saga.

Demo | GitHub

Особенности Fast Data Grid:
— Невероятно быстрый
— Многопоточный
— Всего 523 строчки кода
— Нет зависимостей
— Vanilla JavaScript

Попробуйте скролл и поиск по 1 000 000 строк — Fast Data Grid.

В статье расскажу про работу с потоками.

Меня зовут Олег, и в Яндексе мы с командой занимаемся Python-обвязкой вокруг нашей базы данных YDB. Python знаменит «батарейками в комплекте», широким ассортиментом библиотек на все случаи жизни, включая богатую экосистему для работы с базами данных. Есть свой интерфейс DBAPI (PEP-249), несколько конкурирующих ORM и многочисленные уровни абстракции между софтом и базами. В этой статье — о том, как мы делали полноценную интеграцию нашей базы данных с Apache Superset: чтобы достаточно было выбрать YDB из выпадающего меню и начать визуализировать аналитические данные.

Продолжаем обсуждать серверы в контуре высоконагруженных 1С-систем. В предыдущей статье я рассматривал типичные проблемы с серверами СУБД, а сегодня перейдем к серверам 1С. Причем не хочется, чтобы пост превратился в очередной универсальный перечень настроек сервера 1С на все случаи жизни. Поэтому будем смотреть на задачу через призму производительности системы. Главное, сначала увидеть картину целиком, понять причину и, исходя из этого, менять пусть те же самые настройки 1С.

Цель статьи — подсветить несколько достаточно распространенных, но не всегда очевидных проблем производительности ИТ-системы, находящихся на стороне сервера(ов) 1С.

Естественно, я не планирую разбирать очевидные вещи из серии «Хьюстон у нас проблемы. Нагрузка на CPU — 100%, пользователи в истерике». Но начну как раз с процессора :-). Тут есть что рассказать.

С 12 марта 2024 года метрика FID (First Input Delay) из семейства Core Web Vitals заменена метрикой INP (Interaction to Next Paint), которая оценивает скорость отклика сайтов. При этом, согласно оценке Google, по метрике FID было оптимизировано 93% сайтов, но лишь 65% — по INP. 

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

Меня зовут Кирилл Радыгин. Я руководитель фронтэнд направления в компании Одноклассники. В этой статье я расскажу, как команда ОК адаптировала соцсеть под изменившийся набор метрик оценки перформанса.

Некоторые люди предпочитают пользоваться не только облачными сервисами, но и запускать LLM у себя дома. Например, так можно запустить дообученные модели без цензуры, или не посылать в облако свои личные документы. А то и запускать бесчеловечные эксперименты над LLM так, чтобы superintelligence/skynet потом это не припомнил.

Есть много моделей, оптимизированых для быстрой работы на устройствах с небольшой памятью. Но, к сожалению, веса самых продвинутых моделей, которые играют в одной лиге с лучшими онлайн моделями, занимают сотни гигабайт. Например, 8-битные веса Deepseek R1-671B занимают 700 гигабайт, квантованые q4 — 350 гигов. Можно квантовать и в 1 бит, размер тогда будет около 100 гигов, но такая модель почти бесполезна. Еще есть много качественных finetunes на основе Mistral-Large-instruct-130B, Qwen2.5-72B, llama3.3-70B, веса которых также не помещаются в память старших моделей видеокарт.

Каждому C++-разработчику приходится решать задачи асинхронности — от сетевых запросов до фоновых вычислений. В этой статье вы увидите, как P2300-модель Senders/Receivers в C++26 расширяет возможности std::async/std::future и позволяет строить ясные, декларативные конвейеры (then, when_all, upon_error и др.).

В распределённых системах критически важно обеспечить консенсус – согласованность данных или решений между множеством узлов (серверов), даже при сбоях и задержках сети. Алгоритмы консенсуса позволяют группе несовершенных узлов действовать как единое надёжное целое. Три классических алгоритма – Paxos, Raft и Zab – стали основой для построения отказоустойчивых систем. Они гарантируют, что при наличии кворума узлов (обычно большинства) все узлы придут к единому решению и последовательности операций, сохраняя консистентность данных. В данной статье мы рассмотрим устройство этих алгоритмов «под капотом», их этапы (выбор лидера, репликация журнала, обработка сбоев и восстановление), области применения в реальных системах (от координаторов в кластерах Kubernetes и Apache Kafka до распределённых баз данных), а также сравним готовые реализации (такие как etcd, ZooKeeper, Consul и др.) по ключевым характеристикам.

KPI — это не только инструмент измерения, но и своеобразный стресс-тест для организации. Когда руководство устанавливает амбициозные показатели, команды демонстрируют одну из трех реакций: мобилизуются и находят нестандартные решения, идут на компромиссы и срезают углы, или впадают в ступор.

Эта реакция на давление говорит о компании больше, чем сами цифры достижений, выявляя скрытые проблемы в процессах, культуре и лидерстве. В статье я разобрал, как превратить KPI из инструмента давления в диагностический инструмент и какие сигналы стоит отслеживать.

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

Привет, Хабр! Меня зовут Алексей Чуркин, я работаю в компании Wildberries, где строю приватное облако. В этой статье по мотивам моего доклада для Highload++ расскажу о том, как мы внутри компании построили облачную платформу, с какими сложностями столкнулись и как собираемся её развивать.

Мы начинали с обычного ELK-стека, логи приходили на logstash, записывались в Elasticsearch, а пользователи смотрели их в Kibana. Потом в эту схему добавилась Kafka, так как мы понимали, что на пиках нагрузок не успеваем записать все логи в Elasticsearch. Всё это располагалось в одном ЦОДе, а в Kafka была единая очередь. В результате горизонтального масштабирования Elasticsearch разросся до 30+ нод. Данная схема справлялась с нагрузкой в 100 тысяч документов в секунду.

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

Привет, Хабр! На связи Филипп Бочаров, руководитель платформы наблюдаемости и мониторинга для более 400 продуктов экосистемы МТС, и Юлия Тальцкова, ведущий инженер сервиса логирования и кластеров Open Search с более 400 терабайтами логов клиентов. Этот материал написан на основе нашего доклада для конференции Highload++

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

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

Сергей Каличев, старший разработчик, Angie Software

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

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

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

Я занимаюсь разработкой баз данных с 1999 года и сейчас работаю над YDB — базой данных, которую мы в Яндексе недавно выложили в опенсорс. Это моя шестая база данных и четвертая — массивно-параллельная. И каждый раз, когда основные задачи решены, я сажусь разрабатывать оптимизатор запросов. Под катом я кратко расскажу о том, что такое оптимизаторы запросов в базах данных и почему их непросто делать.

Что же делать на практике для масштабирования data-bounded (т.е. типичных) приложений?

Я опущу длительные рассуждения и представлю свою "поваренную книгу"