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

Привет, Habr! Возможно, кто-то меня даже помнит: совсем недавно я создал Python Framework для асинхронных приложений - Propan.

Два месяц назад я делился с вами прогрессом и говорил, что работа над PropanV2 активно ведется. И вот, она завершена. Вот только вместо PropanV2 свет увидел немного другой фреймворк - FastStream, разработкой которого занимался уже не только я, а целая команда AirtAI.

В рамках статьи я расскажу, чем проекты отличаются, как переехать с одного на другой, ну и конечно, как так вообще получилось. Если вам интересно, как я "продал" opensource проект, и как от этого все остались в выигрыше (особенно пользователи) - добро пожаловать под кат!

Привет, Хабр!

Каждая миллисекунда имеет значение, кэширование стало безусловно важной частью проектирования высокопроизводительных приложений. Оптимизация скорости и доступности данных стала приоритетом для разработчиков, и кэширование является одним из наиболее эффективных способов достижения этой цели. Redis и Memcached играют занимают важную роль в этом процессе.

Redis и Memcached – два из самых популярных и мощных инструментов для реализации кэширования. Redis, изначально разработанный как in-memory хранилище данных, позволяет эффективно хранить и быстро извлекать информацию в памяти, что делает его идеальным выбором для кэширования. Memcached, с другой стороны, специализируется исключительно на кэшировании данных и предоставляет простой, но мощный способ ускорить доступ к данным.

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

Java долгое время была и остается фаворитом в enterprise решениях, но все чаще в высоконагруженных проектах предпочтение отдается более "производительным" языкам, таким как Go, а порой даже C++. Но вдруг Java тоже может быть быстрой?

❓Как проектировать системы, которые будут толерантными для различного вида отказов и ошибок?

Что такое отказоустойчивость и стабильность?

Под отказоустойчивостью будем понимать свойство системы, которое позволяет максимально сохранять работоспособность при отказе отдельных конкретных компонентов системы либо связанных систем и восстанавливать работоспособность системы при восстановлении отказавших компонентов или связанных систем. Давайте рассмотрим подробнее эти 2 момента:

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

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

Корпорация Samsung относительно недавно представила новый форм-фактор оперативной памяти. Он получил название LPCAMM (Low Power Consumption Attached Memory Module). По словам разработчиков, у технологии есть несколько преимуществ, включая компактность и энергоэффективность. Подробности о новинке — под катом.

В нашем предыдущем посте о производительности YDB, посвященном Yahoo! Cloud Serving Benchmark (YCSB), мы упоминали, что готовим к публикации результаты других бенчмарков. Мы придерживаемся плана и сегодня рады представить вашему вниманию наши первые результаты бенчмарка TPC-C*, который является индустриальным стандартом оценки производительности онлайн транзакций (OLTP). Согласно этим результатам есть сценарии, в которых YDB немного превосходит CockroachDB, другую хорошо известную распределенную SQL СУБД.

Технологическая платформа 1С:Предприятие – это большой программный продукт (только на С++ - более 10 миллионов строк кода, а есть ещё Java и JavaScript). Подробнее про устройство платформы можно прочитать тут.

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

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

Мы много лет уже используем в качестве основной базы данных PostgreSQL. За это время он зарекомендовал себя быстрой и надежной СУБД. Однако, есть в PostgreSQL одна проблема, с которой приходится сталкиваться достаточно часто. К сожалению, реализация логики временных таблиц в нем имеет ряд недостатков, которые отрицательно сказываются на производительности системы.

Одним из свидетельств наличия проблемы является то, что для временных таблиц в Postgres Pro была добавлена специальная функция fasttrun, а в Postgres Pro Enterprise существенно доработана работа с ними (см. пункт 4). 

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

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

Буквально на секунду представьте, что у вас есть парочка здоровенных кластеров Apache Kafka, каждый из которых держит по нескольку миллионов rps. И тут вас попросили зеркалировать топик из одного кластера в другой. Максимально близко к реалтайму, да ещё и с некоторыми специфическими условиями. Если стало страшно, интересно или страшно интересно, то это статья для вас.

Под катом я расскажу, что такое зеркалирование и зачем оно нужно. Как нам перестало хватать Mirror Maker’а. Поговорим о возможных решениях и выборе между ними. И дам подробную инструкцию, как вам развернуть такое решение у себя.

Речь пойдёт о трудностях работы инженеров по безопасности в крупной компании – как команда выстроила AppSec и как выбранный подход помог сделать безопаснее “бирюзовую” команду и огромный Enterprise в целом. Это история о самоорганизации, зрелости и уменьшении количества явных контролей в угоду «безопасных» процессов.

В этом нам поможет директор департамента мониторинга и реагирования на инциденты ИБ VK Дмитрий Куколев. У него 12-летний опыт построения процессов безопасного производства. Сейчас он директор департамента мониторинга и реагирования на инциденты ИБ VK.

В субботу прошло первое занятие Школы Синтеза Цифровых Схем. Записалось 650 человек в 15 городах России и Беларуси, пришли 400 (250 офлайн и 150 онлайн). Российский флаг на мониторе нарисован комбинационной логикой FPGA (первое что пришло в голову рисовать студентам сразу в двух кластерах). Вообще обычно на первом занятии мигают светодиодами, но мы решили пойти дальше и показали им как рисовать картинки. Для этого два счетчика формируют X и Y, а задача студента - реализовать функцию RGB (X, Y).

Из-за наличия зоопарка плат, версий Windows и Linux, а также EDA софтвера, глючных программаторов, и при этом свежих и недотестированных bash-скриптов, возникла ситуация полного ада, особенно у онлайн-пользователей (преподаватели на местах героически справлялись). Возникла ошибка, которая меня реально удивила. И не только меня:

Есть такая занимательная структура данных, описанная в статье Russ Cox — sparse map.

Она используется, например, в недрах компилятора Go. А ещё в некоторых пакетах его стандартной библиотеки.

У неё есть много интересных свойств и, чем больше я о ней думаю, тем больше применений нахожу в своих задачах. Казалось бы, всё так хорошо, что лучше быть просто не может. Однако сегодня я расскажу вам о секретной штуке, которая будет экономить ещё больше бесценных наносекунд!

В данной статье делюсь замеченной на практике проблемой. Смысл проблемы заключается в использовании противоречащих подходов на уровне Persistance и DevOps.

Привет, меня зовут Денис Агапитов, я руководитель группы Platform Core компании Bercut. Работаю в компании без малого 20 лет, из них 18 пишу на Java.

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

Эта статья основана на реальной практике борьбы с "OutOfMemory: direct memory".

Любому сайту нужен поиск. Например, на Хабре сотни тысяч статей на самые разные темы. Чтобы отыскать ту самую через хабы и блоги, может потребоваться о-о-очень много времени. Без поиска пользователи могут не найти то, что им нужно, решить, что здесь этого нет и уйти в другой сервис. 

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

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

Около двух лет назад вышла небольшая статья Kafka Streams — непростая жизнь в production, в которой я описывал сложности, с которыми наша команда столкнулась при попытке решить задачи проекта с помощью kafka-streams. Эксперимент вышел неудачным, и мы в итоге совсем отказались от этой технологии. Вместо нее решили попробовать Clickhouse (CH), и сейчас уже можно сказать, что эта база нам очень хорошо подошла и отлично решает почти все задачи, которые нам ставит бизнес. В этой статье я расскажу об особенностях использования CH.

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