Высоконагруженные системы *

Система управления проектами для удаленных команд Virex теперь доступна!

Коммуникация, задачи, аналитика, гибкость — всё это про Virex.

Система управления проектами Virex начинается с простоты. Все проекты в одном месте. Все ключевые данные, задачи и прогресс проекта одном экране.

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

Лента активности Virex: больше не нужно искать, кто, что и когда сделал. Все изменения в проекте собраны в одном месте.

Встроенные чаты для каждого проекта. Общайтесь со своей командой прямо в Virex.

Заходите в Virex прямо сейчас!

https://app.virex.studio

Один из пользователей сервиса Highload.fun Joad Nacer прогнал все задачи через GPT O1 и получил интересный результат:

По 2024 году результат расположился на 20 месте с 3,574 очками, как я понимаю код был на C++. В целом нормально, но я, непрофессиональный кодер на C#, разместился на 23 месте, так что я бы оценил кодерство ИИ на уровне студента 1-го курса непрофильной специальности.

Не являюсь профессиональным программистом на C#, для меня это хобби и много лет меня интересует вопрос, почему косметически минимально изменённая программа на C# может выполняться на десятки процентов или быстрее или медленнее.

Корифеи мне конечно объясняли что мол приложению нужно "прокачаться" перед запуском и даже научили пользоваться бенчмарком для .NET, но забавность еще и в том, что на одной машине бенч может показывать одни результаты, а на другой - другие. И нет, я не про разницу в железе, а о том, что Метод1 на одной машине стабильно быстрее Метода2 на 10%, а на другом ПК - разница просто отсутствует.

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

Первая. Перестановка переменных местами:

int a = 0;
int b = 0;

и следом вариант

int b = 0;
int a = 0;

производительность меняется.

Вторая. Использование for/while:

for(int i = 0; i < 100; i++);
int i = 0; while(i < 100) i++;

еще с 90-х меня учили что в Си-подобных языках конструкции for/while по сути взаимозаменяемы, но в C# почему-то while в некоторых ситуациях оказывается быстрее.

Третья. Обнаружена пару дней назад:

int time = time * 10 + sec - 2;
sec++;

код выше работает медленнее чем

int time = time * 10 + sec++ - 2;

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

Раз в год-два мне приходится вспоминать, что Python — не C++.

В этот раз я наткнулся на случай, когда отформатировать и склеить колонки результата запроса на стороне PostgreSQL и распарсить Python-ом оказалось эффективнее, чем запрашивать колонки как отдельные значения.

Конкретнее, при переходе от этого запроса:

SELECT * FROM o_relations ORDER BY id DESC LIMIT %(limit)s

к этому:

SELECT CONCAT(entry_id::text, '|', tag_id::text) AS ids FROM o_relations ORDER BY id DESC LIMIT %(limit)s

скорость извлечения данных увеличилась примерно в 4 раза.

Причиной тому тяжёлая конвертация данных из формата С в формат Python внутри Psycopg.

За подробностями можно сходить ко мне в блог: https://tiendil.org/ru/posts/fun-case-of-speeding-up-data-retrieval-with-psycopg

50 оттенков кеширования: от in memory к многоуровневому redis-кластеру — Леонид Ченский / Ural Digital Weekend 2024

Опубликовали запись доклада секции «Разработка» с Ural Digital Weekend 2024.

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

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

Итерация 1: in memory cache.

Итерация 2: удаленный шардированный кэш-кластер (redis vs memmcached).

Итерация 3: N-уровневый кэш.

Итерация 4: шардированно-реплицированный multi-DC кэш-кластер Redis.

В конце выступления спикер подвел итог и поговорил об альтернативах KV.

Ссылка на запись доклада в ВКонтакте.

Ссылка на презентацию: https://goo.su/2ik4N

В одной из недавних статей узнал про сайт HighLoad.fun, было интересно решить несколько задач и забраться в лидеры. Если кто-то любит highload задачи, то зову принять участие. Общался с автором проекта HL в телеграме - отзывчивый добродушный человек, планируется версия сервера 2.0 с новыми плюшками. Может и выглядит как реклама, но моя заинтересованность чисто спортивная, я решаю такие задачи сколько себя помню, это как кроссворды для меня, а без конкуренции нет желания улучшать результат. В секции C++ конечно соревновательный дух активнее, но я пишу на C# и там результатов не так много.

Как обрабатывать 5 млн изменяющихся форм в минуту с SLI 99.99% — Кирилл Грищук

Опубликовали запись доклада секции «Разработка» с Ural Digital Weekend 2024.

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

Ссылка на запись доклада в ВКонтакте.

Ссылка на презентацию: https://goo.su/qHW9

Как мы сделали высокоскоростной RPC с помощью RDMA для собственного SDS — доклад на IT-конференции GoCloud Tech 🦾

На конференции GoCloud Tech расскажем, почему выбрали RDMA RoCE v2 — программный блок для потоковой передачи данных. Посмотрим на внутреннее устройство транспорта с позиции разработчика. Покажем, как изменилась производительность RPC между сервисами SDS. Обсудим недостатки и перспективы решения.

Приходите послушать доклад и обсудить тему в неформальной обстановке.

🕚 Когда: 24 октября с 17:40 до 18:05

📍 Где: онлайн и офлайн в Москве в лофт-пространстве Goelro

👉 Зарегистрироваться на GoCloud Tech

Полезное в блоге:

• Что нового слышно о шине CXL: заметки с саммита по вычислениям, памяти и хранению данных

• Математика прекрасного. Как создать красивую картинку, если ты дилетант, художник или нейросеть?

• Зачем нужна R&D-команда: взгляд разработчика

Новые курсы Яндекс Практикума для специалистов с опытом

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

«Эксплуатация и разработка в Kubernetes» — за 3 месяца освоите и примените на практике технологии оркестрации контейнеров. Программу составляли инженеры и тимлиды, которые давно работают с Kubernetes. Благодаря этому, вы будете учиться только тому, что на самом деле пригодится в работе. Ближайший старт — 17 октября.

«Apache Kafka для разработки и архитектуры» — 3-месячный курс для тех, кто хочет влиять на масштабируемость и надёжность систем. С этой технологией вы будете работать с более сложными продуктами и сможете повысить грейд. Есть бесплатная вводная часть. Ближайший старт — 21 ноября. 

«Архитектура программного обеспечения» — за 6 месяцев освоите лучшие практики архитектуры и научитесь решать сложные архитектурные задачи. Есть бесплатная вводная часть. Ближайший старт — 24 октября и 28 ноября.

«Мидл Android-разработчик» — 5-месячная программа для Android-разработчиков с опытом. Курс фокусируется на углублении технических навыков, изучении передовых паттернов и технологий, а также на освоении инструментов и методов, применяемых в реальных проектах. Ближайший старт — 14 ноября.

«Apache Kafka для разработки и архитектуры» — новый курс Яндекс Практикума

Навыки работы с Apache Kafka нужны всем, кто хочет влиять на масштабируемость и надёжность систем. На курсе «Apache Kafka для разработки и архитектуры» за 3 месяца вы научитесь использовать эту технологию, чтобы применять её в работе. 

Курс подойдёт специалистам с опытом: бэкенд-разработчикам, архитекторам, DevOps-инженерам и инженерам данных. Нужно знать Java, Python или Golang, понимать принципы работы с базами данных SQL и NoSQL, базово разбираться в архитектуре распределённых систем и уметь работать с Linux.

Преимущества курса:

• Обучение конкретно Apache Kafka, не в рамках более общего курса;

• Комплексное погружение в инструмент, а не просто знакомство с основами;

• Практические задания в каждом уроке и проекты по окончании спринтов;

• Воршкопы с экспертами, которые помогут разобрать наиболее сложные вопросы.

  Вы научитесь:

• Настраивать Apache Kafka для своих задач и оптимизировать производительность;

• Интегрировать Kafka с внешними системами;

• Работать с производителями и потребителями сообщений;

• Проектировать и реализовывать потоковые пайплайны данных;

• Обеспечивать надёжность и отказоустойчивость систем;

• Настраивать мониторинг кластеров Kafka и управлять им.

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

→ Узнать о курсе подробнее и начать обучение

Сергей Ким, руководитель команды разработки WMS и активный пользователь Яндекс Лавки, рассказал, про внутренний мир Лавок. 

Обсудили: 

• как Яндекс управляет лавками, узнаёт о товарных остатках и рассчитывает время курьеров, чтобы вовремя доставлять все заказы; 

• о чём можно узнать с помощью проактивных пушей изменений и периодического пула всего сразу;

• как перекладывать JSON с минимальным лагом. 

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

Фотонный процессор в России: что за чудо и с чем его едят?

РИА Новости сообщают, что к концу года в России завершат испытания фотонного процессора. Что в нём инновационного и реально ли ждать в нашей стране такое устройство?

Представьте, что вам надо послать сообщение и вы передаёте письмо «Камазом». Почему же не легковой машиной или даже по интернету? Сейчас с вычислительной техникой ситуация плюс-минус аналогичная — информация передаётся с помощью электронов, а ведь у нас есть частицы гораздо легче — фотоны. Массы покоя они вообще не имеют, а значит любые преобразования способны проводить быстрее. Теоретически. А ещё не будет потерь тепла на сопротивление. Вот и получается, что процессор, в котором вычисления проводятся не на электронах, а на фотонах, должен быть быстрее в десятки тысяч раз и с минимальным энергопотреблением.

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

Сможет ли Россия обогнать весь? Материаловедение сейчас развивается во всём мире, и тот же Росатом вовсю работает над новыми материалами. Так что на данном этапе всё возможно. Тем более, что в этом году мы получим только прототип фотонного процессора со скромными характеристиками. К 2030 году российские учёные обещают разогнать его до 1000 экзафлопс при энергопотреблении в 10 000 раз ниже обычного. Звучит фантастично. А ведь потом встанет вопрос серийного производства...

Закрытие темы "Гипотеза о связи относительного количества ожиданий СУБД и производительности СУБД "

Отношение количества событий ожидания влияющих на производительность СУБД к количество событий ожидания не влияющих на производительность в ходе штатной работы СУБД будет примерно постоянное.

Для проверки гипотезы была проведёна серия экспериментов по 3-м сценарям:

1) Базовая(эталонная) нагрузка.

2) Дополнительная нагрузка на CPU/RAM.

3) Очередь ожидания освобождения блокировки строк/таблиц.

Итог: Гипотеза не подтверждается экспериментальными данными : разница в соотношении между ожиданиями составляет ~3% , при деградации производительности ~34%.

Или другими словами: соотношение между ожиданиями при работе СУБД, в общем случае, не зависит от нагрузки и производительности СУБД и остаётся примерно постоянным для конкретной СУБД.

Таким образом - изменение соотношения между ожиданиями СУБД не может являться индикатором деградации производительности.

Тема закрыта. Статья снята с публикации.

P.S. Однако, в ходе экспериментов, получен интересный побочный результат:

При использовании pgbench c параметром "--connect", отношение количества ожиданий влияющих на производительность, к количеству ожиданий не влияющих на производительность - существенно отличается (~38%).

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

Разверните базу данных на выделенном облачном сервере ⚡️

Преимущества DBaaS на выделенном облачном сервере

• Максимальная производительность,

• Экономическая выгода,

• Быстрый запуск,

• Безопасность.

Сделали все для максимальной производительности ваших баз данных

• Собрали конфигурации серверов с высокочастотным процессором Intel® Xeon® Gold 6240 в односокетной сборке с включенным Turbo Boost и Hyper-threading. 

• Используем специальные планки оперативной памяти ECC REG, рекомендуемые для СУБД.

• Для дополнительной отказоустойчивости добавили дисковую подсистему на сверхбыстрых NVMe SSD дисках компании Intel, собранных в RAID1.

• Оптимизировали настройки всех систем на сервере от BIOS до ОС.

Создайте базу данных →

К вопросу о важности определения понятия "производительность СУБД".

Пусть имеется некий запрос к СУБД, который важно мониторить с точки зрения эффективности и качества работы.

Сценарий 1: запрос выдает N1 строк и выполняется за время T1.

Сценарий 2: запрос выдает N2 строк и выполняется за время T2.

Вопрос: можно ли утверждать о инциденте в случае Сценария 2, если "T2 > T1 И N2 > N1" ?

Утверждение: Не имея определения понятия "производительность" и не обладая возможностью рассчитать метрику производительности отдельного запроса, получить однозначный ответ на поставленный вопрос - невозможно.

Леонид Ченский про систему кэширования и топ-3 ошибок в кэшировании

Мы встретились с Леонидом Ченским, руководителем группы разработки в Ozon и спикером секции «Разработка» UDW2024. Леонид рассказала про обучение разработчиков, систему кэширования и топ-3 ошибок в кэшировании.

Ссылка на интервью: https://www.youtube.com/watch?v=yNuAjXKfcMg

Ural Digital Weekend 2024 — одна из крупнейших IT-конференций на Урале с насыщенной программой и аудиторией 400+ человек, организованная компаниями Spectr и Тэглайн. Билеты для посещения конференции уже могут приобрести все желающие на сайте Ural Digital Weekend 2024 — https://ural-digital-weekend.ru/. А по промокоду CHENSKYGIFT10 можно получить приятную скидку.

Надежность — не просто слово, а важное дело

Привет! С вами центр надежности Т-Банка, и мы приглашаем инженеров на SRE-митап.

Где: Москва, офис Space, ул. Грузинский Вал, 7
Когда: 29 июля в 19:00

На встрече вы узнаете:

• как не напрягаясь казаться надежнее, чем есть на самом деле;

• понять, что ест ресурсы в PostgreSQL и как это прекратить;

• построить хранилище логов, если Grep вы уже переросли.

Для тех, кто не сможет прийти на митап, мы проведем онлайн-трансляцию. Регистрируйтесь по ссылке и выбирайте удобный формат участия.

О чем расскажут эксперты

Go: Раскрытие потенциала скорости

Я всегда борюсь за скорость. Началось это все с того, как я прочитал книгу “Грокаем алгоритмы” и меня заинтересовало измерение скорости выполнения. Потом, решая задачи на LeetCode я расстраивался, если алгоритм получался медленным. Недавно мне пришла идея написать пост на эту тему, а во время написания изучить этот вопрос получше. Я прочитал не мало статьей, большинство из которых - англоязычные.Так что вот советы по увеличению скорости Вашего приложения на Golang :

1. Выделять ёмкость для среза с помощью make

При создании среза выделяйте ёмкость с помощью make, так Вы избавитесь от перераспределений

2. При возвращении указателя, объявлять его при создании переменной

 func (r Ruleset) Match(path string) (*Rule, error) {
 	for i := len(r) - 1; i >= 0; i-- {
		rule := r[i] //так НЕ надо
		rule := &r[i] //так надо
 		match, err := rule.Match(path)
 		if match || err != nil {
			return &rule, err //так НЕ надо
			return rule, err //так надо
 		}
 	}
 	return nil, nil
}

3. Пишите бенчмарки

Пишите бенчмарки для вашего приложения, так Вы поймете, в каком месте оно работает медленнее всего. Источник для того, чтобы научиться писать бенчмарки: https://dave.cheney.net/2013/06/30/how-to-write-benchmarks-in-go и др.

4. Используйте горутины!

Когда есть возможность, используйте горутины. Например, когда результат 2-х операций не зависит друг от друга, можете использовать горутины. Думаю, доказывать, что таким образом приложение становится быстрее, не надо :)

Привет! Мы проводим SRE Week — открытый интенсив по теме Site Reliability Engineering от Школы анализа данных и экспертов Yandex Infrastructure. 

О чём интенсив

Site Reliability Engineering — область, посвящённая эксплуатации больших и нагруженных компьютерных систем. Если вы хотите делать сервисы, способные выдерживать значительные нагрузки и работать на большом количестве железа, вам придётся столкнуться и с вопросами эксплуатации. 

Программа интенсива

На интенсиве будет пять лекций и один семинар, занятия пройдут с 17 по 22 июня.

На лекциях:

• посмотрим на поломки больших систем, общие принципы, статистику аварий и разберём конкретный инцидент;

• научимся производить диагностику одного сервера и определять ограничения по железу, так как большие системы строятся из отдельных серверов;

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

• обсудим, из чего состоит ежедневная работа в эксплуатации и как организована работа в команде. 

На семинаре:

• научимся настраивать ядро Linux для повышения производительности; 

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

Как принять участие

Для участия в интенсиве зарегистрируйтесь по ссылке. Регистрация открыта до 16 июня. Для получения доступа к итоговому практическому заданию нужно пройти отбор до 22 июня и сдать задание до 3 июля. Тем, кто успешно справится, будет выдан сертификат.

Разбор доклада Артёма Арутюняна про Архитектуру и Реактивное Программирование

Топ перлов:

• Реактивное программирование - это программирование на событиях.

• Реактивность нужна между модулями, а внутри - не нужна.

• По одному лишь графу связей можно понять правильно произведена декомпозиция или нет.

Мета: Копилка благодарностей, Новости, Форум