Привет! Меня зовут Олег Кретинин, и я разработчик в команде общих компонентов в Яндекс Еде. Сегодня я расскажу о том, как мы смогли успешно снять нагрузку с нашей базы данных, а также уменьшить её размер.

Помимо сервисов, написанных на C++, Go и Python, у нас есть монолит, он же «кора», на PHP, который всё ещё представляет огромную кодовую базу, хранит кучу логики и предоставляет данные по API для 120 сервисов.

После обновления фреймворка и версии PHP мы принялись за решение другой проблемы, которая всё чаще и чаще давала о себе знать. В тот период у нас возросло количество инцидентов, связанных с базой данных, и нам нужно было что‑то придумать, чтобы стабилизировать проект максимально быстро. Случалось, что всё сыпалось во время праздничных дней, когда количество заказов увеличивалось на 30–40%, или во время разовых массовых операций, например когда однажды в большую сеть ресторанов добавлялся бесплатный соус к каждой позиции меню.

tl;dr

Cжатие изображений всегда должно быть автоматизировано

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

serde — основной фреймворк для сериализации и десериализации в Rust. Его используют как крейт по умолчанию во всей экосистеме. serde_json — это официальный serde-миксин для JSON, так что каждый раз, когда нужно что-то парсить, люди обращаются именно к нему. Конечно, есть и другие библиотеки, специализующиеся на парсинге JSON, например simd-json, но популярность у них, мягко говоря, удручающая. serde_json значительно популярнее: на момент написания от него зависят аж целых 26916 крейта, а от simd-json — всего 66.

Это делает serde_json хорошей мишенью (не как у Jia Tan) для оптимизаций. Велик шанс того, что многим из тысяч пользователей переход на simd-json позволил бы добиться ускорения, но, пока они этого не делают, более мелкие оптимизации — лучше, чем совсем ничего, и такие улучшения — глобальный выигрыш для экосистемы.

Все говорили о микросервисах. Гибкость. Масштабируемость. Независимые команды. Звучало как мечта. Многие компании бросились распиливать свои монолиты. Разработка действительно ускорилась. Отдельные компоненты стало проще обновлять и разворачивать.

А потом сервисам понадобилось общаться. И мечта превратилась в сложную, многомерную головоломку.

К нам обратился заказчик из сфера развлекательного видеостриминга с интересной проблемой - у него сервера падали не одновременно. А очень хотелось бы добиться синхронности.

Сервера, которые смущали заказчика работали в роли бэкенда для хранения видеофайлов. По сути, это было множество узлов, содержащих десятки терабайт видеофайлов, которые предварительно были нарезаны в разном разрешении конвертерами. Затем, все эти миллионы файлов отдавались во внешний мир с помощью nginx + kaltura, что позволяло перепаковывать на лету mp4 в сегменты DASH/HLS. Это позволяло хорошо переносить даже высокие нагрузки, отдавая плеером только нужные сегменты без резких всплесков.

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

Всем привет! Я бэкэнд-разработчик, пишу микросервисы на Java + Spring. Работаю в одной из команд разработки внутренних продуктов в компании Тинькофф.

У нас в команде часто встает вопрос оптимизации запросов в СУБД. Всегда хочется еще чуть-чуть быстрее, но не всегда можно обойтись продуманно выстроенными индексами — приходится искать какие-то обходные пути. Во время одного из таких скитаний по сети в поисках разумных оптимизаций при работе с БД я нашел бесконечно полезный блог Маркуса Винанда, автора книги SQL Performance Explained. Это тот самый редкий вид блогов, в котором можно читать все статьи подряд.

Хочу перевести для вас небольшую статью Маркуса. Ее можно назвать в какой-то степени манифестом, который стремится привлечь внимание к старой, но до сих пор актуальной проблеме производительности операции offset по стандарту SQL.

Уже несколько лет компания AMD предлагает совершенно атомные, а точнее ядерные, а ещё точнее суперМНОГОЯДЕРНЫЕ процессоры Epyc. В этой статье мы рассмотрим основные «бутылочные горлышки», настройки биос и другие вещи, которые мешают раскрыть потенциал этих процессоров.

Недавно я писал статью - что такое 50% cpu? На системах с hyperthreading 50% cpu по метрикам означает, что большая часть ресурсов сервера уже использована. То есть cpu>50% - это уже "желтая зона", и мы ожидаем замедление всего, чего можно. Но я никогда не думал до экспериментов, что падение может быть столь катастрофическим.

Для экспериментов я использую MSSQL. Если вы не связаны с базами, прочитайте первую часть по диагонали до выводов.

Перевод статьи Christopher Pitt.

PHP разработчикам не так уж часто приходится следить за расходом памяти в своих приложениях. Сам движок PHP неплохо подчищает мусор за нами, да и модель веб-сервера с контекстом исполнения, "умирающим" после выполнения каждого запроса, позволяет даже самому плохому коду не создавать больших долгих проблем.

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

Последняя проблема и будет рассмотрена в этом уроке.

Введение

Python стал самым популярным языком во многих быстроразвивающихся областях, таких, как глубокое обучение и различные направления анализа и обработки данных. Но при этом за удобство работы с Python-кодом, за высокий уровень его читабельности, приходится платить производительностью. Конечно, все мы время от времени жалуемся на скорость работы программ, и Python, безусловно, не стоит винить во всех грехах. Несмотря на это, справедливым будет заявление о том, что природа Python, интерпретируемого языка, не способствует высокой производительности кода, особенно когда речь идёт о «тяжёлых» вычислениях (один из признаков таких вычислений — наличие в программе нескольких вложенных циклов).

Если вы когда-либо попадали в одну из следующих ситуация — тогда эта статья, определённо, написана для вас.