Методы получения высокой производительности систем
Праздник «день программиста» отмечается в 256-й день года, а это 2⁸, т.е. два в степени восемь. Это не просто так — на степенях двойки многое завязано в компьютерах и программировании, они повсюду. Настолько повсюду, что иногда даже слишком.
Благодаря празднику я вспомнил, что давно хотел написать эту статью, и поделиться несколькими техническими байками, где числа, являющиеся степенями двойки, вставляли «палки в колёса» мне или моим коллегам.
Один из самых частых советов программистам, особенно начинающим, гласит, что они должны писать «чистый» код. Это понятие сопровождается длинным списком правил, которые указывают, что вы должны делать, чтобы ваш код был «чистым». Вопрос, который я хотел бы задать — если мы напишем код, следуя этим правилам, какова будет его производительность?
Как ускорить запуск JVM? Каково переходить с SQL на Cassandra? Что нас ждёт в Java 21? Как профилируют в Alibaba? Какие части Java были сделаны в России? И как в названия докладов на Java-конференции прокралось не только слово «Kotlin», но и «Python» с «PHP»?
На все эти и многие другие вопросы ответит Joker 2023. До конференции остался месяц, её программа готова — представляем её Хабру.
Привет! Меня зовут Сергей, я технический эксперт в компании Bercut. Когда-то увлекался Delphi и J2ME, издал несколько книг на эти темы, и профессионально уже около 20 лет создаю высоконагруженные приложения баз данных, используя для этого PL/SQL и SQL.
В Bercut мы занимаемся разработкой и развитием IT-продуктов и решений для операторов цифровых услуг и мобильных сервисов. Наши системы работают на различном железе, разных СУБД и обслуживают 24x7x365 в режиме онлайн сотни миллионов абонентов по всему миру. И это только кажется, что абонент один раз в день куда-то позвонил и все, больше никакой нагрузки от него нет и никто с ним не работает. На самом деле каждый смартфон каждого абонента непрерывно обменивается данными с сетью, а это все работа инфраструктуры операторов сотовой связи, а значит, нашего ПО. Как же система справляется с таким огромным объемом нагрузки?
Сегодня расскажу, что нужно делать и чего избегать, чтобы построить максимально производительную систему на примере СУБД Оракл.
Redis — это фундаментальная технология, и поэтому мы время от времени встречаем людей, рассматривающих альтернативные архитектуры. Несколько лет назад эту тему подняла компания KeyDB , а недавно новый проект Dragonfly заявил, что является самым быстрым Redis-совместимым хранилищем данных в памяти. Мы верим, что эти проекты привносят много интересных технологий и идей, достойных обсуждения. Нам в компании Redis нравятся такого рода вызовы, поскольку они требуют от нас подтверждения архитектурных принципов, с которыми изначально был разработан Redis (снимаем шляпу перед Сальваторе Санфилиппо, также известному как antirez).
Хотя мы всегда ищем новые вызовы для инноваций и повышения производительности и возможностей Redis, мы хотим поделиться своей точкой зрения и некоторыми размышлениями о том, почему архитектура Redis остается лучшей в своем классе для хранилища данных в памяти в режиме реального времени (кеш, база данных и все, что между ними).
Павел Агалецкий, ведущий разработчик в юните Platform as a Service в Авито, рассказал про семантики или гарантии доставки сообщений, и почему с ними не всегда просто разобраться.
"Не используйте регулярки - иначе вместо 1 проблемы, у вас их станет 2!" - как то так говорят знатоки... А что остается делать непослушным, желающим эффективный поиск по большому количеству шаблонов?
Да, для такой довольно специфичной проблемы существуют крутые решения вроде Ragel или re2c. Тем не менее, для своего проекта мне показалось нецелесообразным пока осваивать эти прекрасные технологии.
В этой статье мы рассмотрим альтернативы стандартной библиотеке для регулярных выражений в Go, проведем их бенчмарк по скорости и потребляемой памяти. А также с практической точки зрения рассмотрим различия между ними.
Всем привет!
Продолжаем цикл статей по разработке браузерного движка.
Да, лучше поздно, чем никогда. Да, перерыв был большой.
В конце статьи я опишу, как поживает проект lexbor, что с ним происходит.
В этой статье я постараюсь раскрыть особенности парсинга Cascading Style Sheets (CSS). Расскажу, как вывернуть «ежа» наизнанку и как тестировать полученный результат.
В CSS спецификациях всё разжевано, ну, или почти всё, тут я расскажу, как всё устроено, куда смотреть и с чего начать.
Эта статья больше обзорная, здесь не будет мелких подробностей реализации, скорее, общие сведения и основные алгоритмы. За мельчайшими подробностями прошу в код на GitHub.
И конечно, как это обычно бывает, мы замахнёмся на звание самого быстрого парсера CSS.
Об инструментах и порядке действий для достижения промежуточного, но заметного результата в задаче по оптимизации высоконагруженного сайта. Полезные ссылки внутри.
Привет, Хабр! В команде ВКонтакте существует система управления репликацией и консенсусом в кластере, которая называется BARSiC (Binary Asynchronous Replication with Simple Consensus). Прежде всего она контролирует состав кластера, определяя, кто реплика, а кто — мастер. А при выходе мастера из строя реплики выбирают нового с непротиворечивой линейной историей.
Для решения этой задачи команда ВКонтакте совместно с университетом ИТМО работали над научно-исследовательским проектом «Разработка моделей для верификации распределенных алгоритмов в системе BARSiC». В этой статье подробно расскажем о том, как мы в рамках проекта верифицировали выбранный для BARSiC алгоритм, и попутно исправили найденную в нём ошибку.
Пару дней назад я агитировал всеми уважаемого эксперта в хранилищах данных за новый стандарт суррогатных ключей UUIDv7 для высоконагруженных систем. И я получил от него ответ, что суррогатные ключи не нужны, а нужны лишь бизнес-ключи (естественные ключи). Этот абсурдный ответ заставил меня написать ответное письмо, а затем и эту статью.
Среди применяемых в PostgreSQL методов доступа к данным Index Only Scan стоит особняком, считаясь у многих разработчиков "волшебной пилюлей" для ускорения работы запроса - мол, "Index Scan - плохо, Index Only Scan - хорошо, как только получим его в плане - все станет замечательно".
Как минимум, это утверждение неверно. Как максимум, при определенных условиях может вызвать проблемы чуть ли не на ровном месте.
Всем привет!
Меня зовут Владимир Олохтонов, я руковожу командой разработки в отделе Message Bus, который является частью платформы Ozon. Мы занимаемся разработкой самых разных систем вокруг Kafka, etcd и Vault. В этой статье я расскажу о том, как мы строили линейно масштабируемую gRPC-прокси перед Kafka, способную обслуживать миллионы запросов в секунду, используя Go.
Привет! Меня зовут Александр Смолин. Я бэкенд-разработчик в команде Яндекс Игр. Уже два года мы используем YDB для задач сервиса. В статье расскажу, как мы в Яндекс Играх внедряли YDB, зачем это было нужно, с какими сложностями столкнулись и какие результаты у нас сейчас.
Реализацией RPC запросов поверх брокеров сообщений никого не удивишь: очередь для запроса, очередь для ответа — ничего сложного.
Тот же RabbitMQ имеет пример в официальной документации. Других примеров там нет, поэтому создается впечатление, что отправка ответных сообщений в другую очередь — единственный возможный способ реализации RPC.
Этот сценарий отлично работает когда у нас есть непрерывный поток сообщений и непрерывный поток ответов на них. Однако, данный подход не применим в случаях, когда нам нужно отправить только одно сообщение и получить ответ именно на него. Мы сразу же попадаем в какой-то ад с фильтрацией ответов по correlation_id.
На самом деле, в RabbitMQ есть механизм и для такого сценария. Но он спрятан в недрах документации и о нем почти нет информации в интернете (особенно рабочих примеров кода).
Вот это недоразумение мы сейчас и исправим.