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

Меня зовут Александр Певненко, я Java developer в СберТехе. Вместе с командой развиваю Platform V DataSpace — BaaS-продукт, обеспечивающий базовые сервисы для работы с данными.

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

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

Поэтому здесь я приведу несколько «базовых» алгоритмов, знание которых помогает мне работать с прицелом на эффективность кода, и дополню примерами на Python и Java.

Большинство инженеров, работающих с машинным обучением, уже знакомы с форматом данных ONNX. Его часто используют для хранения обученных моделей и конвертации их мeжду фреймворками.

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

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

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

Как определить, что утилизация ресурсов кэширования происходит оптимально? Что если довольно большая часть нагрузки не приносит реальной пользы, и от нее с легкостью можно избавиться, тем самым разгрузив хранилище? В рамках этой статьи мы оценим эффективность кэширования бэкeнда ЛК МегаФон и расскажем о результатах проведенных мероприятий для оптимизации.

Павел Агалецкий, ведущий разработчик в юните Platform as a Service в Авито, рассказал про семантики или гарантии доставки сообщений, и почему с ними не всегда просто разобраться.

"Не используйте регулярки - иначе вместо 1 проблемы, у вас их станет 2!" - как то так говорят знатоки... А что остается делать непослушным, желающим эффективный поиск по большому количеству шаблонов?

Да, для такой довольно специфичной проблемы существуют крутые решения вроде Ragel или re2c. Тем не менее, для своего проекта мне показалось нецелесообразным пока осваивать эти прекрасные технологии.

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

Всем привет!

Продолжаем цикл статей по разработке браузерного движка.

Да, лучше поздно, чем никогда. Да, перерыв был большой.

В конце статьи я опишу, как поживает проект lexbor, что с ним происходит.

В этой статье я постараюсь раскрыть особенности парсинга Cascading Style Sheets (CSS). Расскажу, как вывернуть «ежа» наизнанку и как тестировать полученный результат.

В CSS спецификациях всё разжевано, ну, или почти всё, тут я расскажу, как всё устроено, куда смотреть и с чего начать.

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

И конечно, как это обычно бывает, мы замахнёмся на звание самого быстрого парсера CSS.

Привет, Хабр! Меня зовут Михаил Сапрыкин, я ведущий инженер разработки в Сбере. Наша команда развивает систему антифрода. Раньше мы работали с Apache Ignite, но затем перешли на Platform V DataGrid — распределённую базу данных в оперативной памяти для высокопроизводительных вычислений, которую разрабатывает СберТех.

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

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

Привет, Хабр! В команде ВКонтакте существует система управления репликацией и консенсусом в кластере, которая называется BARSiC (Binary Asynchronous Replication with Simple Consensus). Прежде всего она контролирует состав кластера, определяя, кто реплика, а кто — мастер. А при выходе мастера из строя реплики выбирают нового с непротиворечивой линейной историей. 

Для решения этой задачи команда ВКонтакте совместно с университетом ИТМО работали над научно-исследовательским проектом «Разработка моделей для верификации распределенных алгоритмов в системе BARSiC». В этой статье подробно расскажем о том, как мы в рамках проекта верифицировали выбранный для BARSiC алгоритм, и попутно исправили найденную в нём ошибку. 

В интернете невероятное количество статей о том "как написать свой генератор на С++20", но почти все они сводятся к новичковым хело вордам и почти ни одной статьи о том как написать хороший генератор. Что ж, это нужно исправлять!

Пару дней назад я агитировал всеми уважаемого эксперта в хранилищах данных за новый стандарт суррогатных ключей UUIDv7 для высоконагруженных систем. И я получил от него ответ, что суррогатные ключи не нужны, а нужны лишь бизнес-ключи (естественные ключи). Этот абсурдный ответ заставил меня написать ответное письмо, а затем и эту статью.

В настоящее время известно большое число систем счисления. Подробный перечень (не знаю, насколько полный) приведен в англоязычной Википедии. В этом списке я не нашел ту систему, которая будет изложена здесь. Она относится к классу систем с переменным основанием (mixed radix). Предлагаю ее назвать Flexible number system with a Prime Radixes, сокращенно FPR-системой счисления.

Но для того, чтобы ее понять, необходимы знания некоторых понятий алгебры кортежей (АК) и частично упорядоченных множеств хотя бы в том объеме, который имеется в соответствующей статье в Википедии. Об АК кратко было рассказано в статье «Как совместить логику и семантику в одной алгебраической системе». Там же есть ссылки на публикации с более подробным описанием АК.

В данной статье будут обоснованы следующие преимущества предложенной системы счисления:

• она универсальна - позволяет ТОЧНО выразить все (за исключением нуля) конечные целые и рациональные (с любым ненулевым целым числом в знаменателе) числа, а также некоторые классы иррациональных чисел;

• ее использование позволяет сократить вычислительную сложность алгоритма умножения чисел;

• в ней существенно уменьшается объем памяти для записи и хранения многих больших чисел.

Пару месяцев назад я рассказал вам о своем фреймворке для работы с различными брокерами сообщений - Propan.

Тезисно повторю: это идейный наследник FastAPI, но для написания асинхронных микросервисов (привет, Kombu). Он настолько облегчает взаимодействие с брокерами сообщений, что данный архитектурный паттерн переходит из разряда

слишком сложно, это для хайлоад, некогда разбираться

в разряд

а давай отдадим нашему стажеру сервис, он по документации разберется

(Причем это реальный кейс)

Иногда полезно оглянуться назад, подвести черту и сложить в одну кучу все, что накопилось за время работы. И вот этот момент настал и для Propan. Я просто хочу вам рассказать о тех важных изменениях, которые я внедрил за прошедшие два месяца и планах на будущее.

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

Среди применяемых в PostgreSQL методов доступа к данным Index Only Scan стоит особняком, считаясь у многих разработчиков "волшебной пилюлей" для ускорения работы запроса - мол, "Index Scan - плохо, Index Only Scan - хорошо, как только получим его в плане - все станет замечательно".

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

Кратно увеличим производительность приложения на основе xmlrpc.server из стандартной библиотеки Python.

Иногда (часто) во время разработки веб-сайта возникает необходимость реализовать поиск с фильтрацией, и отсортировать результаты по какому-то фиксированному полю: например, поиск товаров в интернет-магазине, поиск туров в турагентстве, показ логов с фильтрацией по содержимому, и т.д. Очень часто бывает так, что фильтрация должна осуществляться чуть ли не по любому полю (а полей десятки), а записей тысячи или даже миллионы. Если данных много, или же нужно их часто обновлять, то индекс на каждое поле не создать, ибо много места будут занимать, или же будут создавать слишком большую нагрузку на диск при записи, и приходится что-то придумывать. Давайте что-нибудь придумаем.

Всем привет! 

Меня зовут Владимир Олохтонов, я руковожу командой разработки в отделе Message Bus, который является частью платформы Ozon. Мы занимаемся разработкой самых разных систем вокруг Kafka, etcd и Vault. В этой статье я расскажу о том, как мы строили линейно масштабируемую gRPC-прокси перед Kafka, способную обслуживать миллионы запросов в секунду, используя Go.