System design #архитектура

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

Почему это актуально? Ну, например, относительно недавно на собеседовании в одну немаленькую контору, мне предложили рассказать фактически вот это, про Twitter. Собеседование состояло из трёх секций, эта секция называлась "дизайн информационных систем" (system design). Популярная штука, рекомендую подготовиться заранее.

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

Dragonfly #решение

Если кто пропустил, ребята написали свой Redis и назвали это Dragonfly. Сообщают о приросте производительности в 25 раз и экономии 30% памяти. Я погонял на пет проекте с помощью memtier_benchmark и пары скриптов в Postman - остался доволен.

Сегодня я снова услышал про Dragonfly в подкасте RadioDotNet. Оказывается, автор RavenDB (БД на C#) тоже написал пару строк о "своём Redis'е". Естественно, с использованием C#. Чтение занимательное, рекомендую.

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

17 сентября в Нижнем Новгороде будет конференция по .NET. Расскажут про культуру документации, надёжные интеграции и MediatR. Про микрооптимизации буду вещать я.

#лекция

Давайте рассказывать про ЗП #деньги

Я люблю писать и беседовать про деньги, но это почему-то не всегда приветствуется. Тем не менее, я считаю, что это важно. Это позволяет коллегам знать о том, что они чего-то стоят.

Недавно получил подтверждение, что наши компании способны давать весьма конкурентную зарплату. Я имел удовольствие сравнивать предложение компании из Силиконовой долины и нашего аналога IKEA. Батл вышел великолепный, но, на удивление, равный.

Из США предлагали древнее легаси на C#, полное отсутствие микросервисов и всяких модных шутк, но за очень приличные деньги.

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

Почему я это пишу? Я сторонник открытых цифр по зарплате, так как это помогает нам (работникам) понимать, а, собственно, сколько мы стоим. И, надеюсь, это позволит всем нам не соглашаться на полумеры.

В преддверии мероприятия, я рекомендую ознакомиться с интересными статьями: почему не нужно использовать MediatR (статья на русском тут) и почему его использовать круто.

Вообще, к MediatR у меня много претензий, в том числе по перформансу. Если вы пойдёте по ссылке, я замечу, что эта библиотека не рекомендуемая для работы в проде.

Ещё немного бенчмарков по MediatR можно найти тут. Детальный рассказ по перформансу тут.

#архитектура #решение #скорость #память

High-performance design patterns #лекция #скорость #память

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

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

Андрей Акиньшин #скорость #память

Ещё одного парня рекомендуют. Автор мема "Зависит!" в плане микро-бенчмаркинга. Ну, типа, всё зависит от среды исполнения. А-то мы не знали.

Собственно, Андрей - один из авторов Benchmark.NET. Парень не выдержал особенности GC, нового JIT и сильно ударился в статистику. И Huawai. Очень рекомендую ранние выступления и книгу.

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

Микрооптимизации в .NET #лекция #скорость #память

Недавно рассказывал про микрооптимизации. Видео можно посмотреть, а презентацию - скачать. Успехов!

Марк Симан #архитектура

Хочу рассказать про одного датчанина, имя которого я никак не могу запомнить, но, при этом, отлично помню его фото в блоге. Вы можете знать его по AutoFixture - он является одним из авторов.

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

Графика HTMLCanvas #графика #скорость

Рекомендую хорошую статью про Rust, SIMD, WebAssembly и GPU. Разницу в подходах можно пощупать онлайн. В принципе, вывод очевиден - использовать GPU при работе с графикой сильно выгоднее. Однако путь автора и попытки добиться высокой производительности без GPU потрясают.

Эта статья (вернее, её первая часть) стала для меня важным мостиком в мир Rust и WebAssembly. До этого я не очень представлял, как вообще всё это заставить работать вместе.

Скрипты в .NET #решение

Однажды я искал библиотеку, чтобы писать скриптики на JS и работать с ними из .NET. Ну знаете, достать из БД логику, которую написал заказчик без участия программиста, на лету изменить поведение приложения, розовые пони... эх, мечты-мечты.

Но библиотеку я запомнил. Поэтому, могу рекомендовать познакомиться с ней тем, кто ещё хочкт прикрутить скриптики на JS. Бенчмарки неплохие, парни из RavenDB и Orchard используют.

Как работает память #память

Читаю тут текст для настоящих мужиков. Это про то, как "организована память" в .NET. До этого были догадки, были комментарии от создателей, но не было какого-то обобщающего документа от MS.

Вчитываясь в текст, я всё отчётливее понимаю: теперь на собеседованиях можно отвечать "зависит", когда меня попросят реализовать паттерн Singleton. Ведь атомарность действий зависит от платформы.

Узнал про это из подкаста Radio Dotnet. В этом выпуске около часа рассказывают про оптимизации в .NET 7. Очень занимательно.

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

Тинькофф написал статью про последние митапы про .NET. Я там тоже есть, но в данном случае хочу порекомендовать вот это (про оптимизации компилятора, осторожно - много IL). И вот это (про lock-free, но на самом деле про обычные concurrent-коллекции).

Руслана (про боль и микросервисы) с Николаем (проектная документация) тоже порекомендую. Их доклады не совсем по теме канала, но они клёвые.

#статья

PostgreSQL vs MongoDB #хранилище #лекция #решение

Рекомендую достаточно старое видео на тему PostgreSQL vs MongoDB. Недавно пересматривал из-за необходимости выбора. Остановился на PG. Сразу после этого видео рекомендую второе. Оно в тему.

Во втором видео есть интересное объяснение того, что такое highload (high-volume). По версии "человека с лицом индейца" (его зовут Олег Бартунов, если что), это "ситуация в системе, грозящая отказом в обслуживании из-за недостатка ресурсов". Там же про ошибки проектирования. Напомню, что "проектированием" иногда называют само программирование. То есть ваша логика должна быть заточена на highload.

Dapper #решение #хранилище

Я сомневаюсь, что сидящие тут люди не знают про то, что такое Dapper. Но иногда меня очень просят рассказать о том, через что достигается максимальная производительность.

Так вот, Dapper. Это просто data-mapper. Собственно, именно то, что вам нужно иметь для получения ответа от DB. Он тупо создаёт объектное представление из данных, которые возвращает в БД. Запрос вы пишете сами. Прям в коде, да. В 60% случаев вам нужно именно это.

Да, у него нет контекста (см. Entity Framework), да, SQL вам нужно писать самим (на самом деле нет и нет). Но возможность писать оконную функцию без бубна, возможность писать взаимодействие с JSONB, возможность бежать по view, возможность использовать поиск, dirty read... Ну это многого стоит.

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

Честный TechEmpower #бенч #статья

Мужчина очень хорошо рассказал на тему качества бенчмарка Web Framework Benchmarks от TechEmpower.

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

Также, меня радует, что тест уровня Core MVC + EF + PG (самый плохой тест) с моей точки зрения показывает хороший результат - 184k запросов в секунду. Да, это не топ. Да, эту цифру нужно уменьшить до 18-20k за счёт дополнительных слоёв проверок, абстракций типа Mediator и всего прочего.

Но это 20k запросов в секунду. Которые, при желании, можно превратить в 184k или даже в результат синтетического теста (400k+ запросов). Было бы желание.

Хороший GUID #хранилище #решение #статья

Недавно вдумчиво читал статью про медленную работу Guid.NewGuid() на некоторых версиях Linux. Интересно, что про подобное я уже слышал на Radio Dotnet, но в контексте создания GUID, основанных на времени (это помогает, например, забирать сущности из БД по одной страничке для UI).

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

И обязательно посмотрите на рассуждения Эндрю Лока о монотонно возрастающих GUID . Их использование потенциально способно решить проблему фрагментации индекса в MSSQL (увеличение времени вставки, поиска по ID из-за разреженности индекса и рост размера БД). Говорят, что PostgreSQL таким не страдает, но не мешает проверить. Готовое решение для создания монотонно возрастающих GUID называется NewId.

Подробно про это всё написали вот тут.