Весной мы провели DotNext 2021 Piter. А теперь, пока готовим следующий DotNext (пройдёт 21-22 октября), выложили на YouTube видеозаписи весеннего.

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

Если вы .NET-разработчик, то почти наверняка в списке есть что-то, полезное для вас: там и перформанс, и глубокая отладка, и БД с разных ракурсов, и даже детективное расследование.

10: Наблюдаемость систем и процессов

Слово «наблюдаемость» можно услышать не только на DevOps-конференциях (кстати, такую мы тоже проводим). Судя по тому, как регулярно возникает эта тема на DotNext, она интересует многих .NET-разработчиков.

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

С ростом количества продуктов растет экосистема, и соответственно, ее сложность. Наблюдаемость помогает эту сложность снизить. Но важно понимать, что наблюдаемость – не бесплатное удовольствие (что, в общем-то, очевидно), особенно для высоконагруженных систем, и баланс наблюдаемости зависит от зрелости системы.

В докладе Филипп Бочаров — руководитель проектов по разработке в МТС — рассказывает о распределенной трассировке процессов, логировании и сборе метрик.

9: Боремся с сетевым оверхедом в распределённых системах

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

В докладе идет речь об организации данных в распределенных системах, о перформансе и оверхеде. Автор сравнивает традиционный подход, разделяющей данные и логику, с альтернативным комбинированным подходом и рассказывают, что сетевые издержки играют заметную роль в общей производительности системы. Зритель узнает, сколько стоят сетевые вызовы и к каким расходам ведет традиционный подход. А также поймет, как сейчас себя чувствует .NET в мире распределенных систем, где исторически больше присутствовала Java.

В финале — QA-сессия, где Павел говорит о потокобезопасности, узлах и быстродействии и как продукт пришел к опенсорсу.

8: Точечная переработка драйвера MongoDB

Станислав Сидристый известен как специалист по всему низкоуровневому. И здесь как раз ныряет глубоко: не каждый день люди переписывают драйвера для ускорения их работы!

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

Для начала нужно понять, а действительно ли есть проблема? Если что-то на первый взгляд выглядит так себе, это не значит, что за это стоит браться. Все мы знаем принцип «Работает — не трогай». Важно ответить для себя на следующие вопросы:

Какой процент планируемого к оптимизации кода будет работать в конечном сервисе?
Как он повлияет на систему?
Какой процент времени освободит?
Убедиться, что проблема не в железе
Что недозагружено? Что перегружено? Сеть, процессор?

И если решили, что оптимизацию все-таки надо проводить, то начинайте через proof of concept, чтобы не делать бесполезную работу.

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

7: Debugging one layer deeper

Кевин Госсе уже выступал на DotNext на тему отладки (например, в докладе «Debugging asynchronous scenarios in .NET»). Но в этот раз он предлагает спуститься на уровень ниже обычного.

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

Следующий уровень уровень — это когда причины кроются в BCL, стандартной библиотеке .NET. Здесь посложнее, потому что исходного кода в вашей IDE нет. Но его можно найти в репозитории .NET Core, так что даже в такой ситуации вы не выходите за рамки комфортного .NET-мира.

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

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

Например, он рассматривает такую ситуацию: есть среда разработки с двумя серверами, на которых работает CMS Orchard, и сервера получают автоматизированный трафик. Один из серверов является базовым сервером, на котором запущено приложение архивации как есть, а другой запускается с установленным инструментарием Datadog, и поэтому, отслеживая оба сервера, можно обнаружить любые нежелательные побочные эффекты, которые могут быть вызваны инструментами. И сервер, на котором были установлены инструменты, падает примерно раз в день с ошибкой AccessViolation. Что делать?

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

Не будем раскрывать интригу — смотрите все сами. Вас ждет и погружение в ассемблер, и проверка исходного кода .NET, и много чего другого.

6: Techies in Virusland

Федерико Лоис — соучредитель Corvalius, научно-исследовательской компании, и руководитель отдела исследований в RavenDB, уже как десять лет работает над алгоритмической производительностью. Его опыт варьируется от настройки производительности банковского ПО до оптимизации ядра СУБД. Вы могли видеть другие его доклады, которые были максимально хардкорными.

И казалось бы, что он тогда забыл «в Вируслэнде» (в наше время будто бы все стали вирусологами), что собрался делать с коронавирусом? Конечно же, измерять и анализировать! В июле 2020 года команда Лоиса начала исследовать пандемию, чтобы ответить на вопросы, будет ли вторая волна, и что со всем этим можно сделать.

В докладе приводится реальный кейс SARS-CoV-2 waves in Europe: A 2-stratum SEIRS model solution. Взяв за основу модель SIERS для динамики инфекционных заболеваний, Лоис с коллегой в своей работе пытаются разработать действенные стратегии во время второй волны эпидемии SARS-CoV-2. Следить за ходом рассуждений и исследований очень интересно, но как сказал сам Федерико, проводить реальные измерения эпидемического поведения сложно.

В итоге заезженная тема коронавируса становится намного интересней, если взглянуть на нее под другим углом — исследовательским. Тогда она превращается в работу с данными, создание моделей и гипотез, формулы и уравнения.

5: Behind modern concurrency primitives

Тема конкурентности и многопоточности — сложная, в асинхронном программировании возникают множество нюансов и нередко вылезает непредвиденное поведение программы. И тут полезны знания Бартоша Сыпытковски. Он любит разбираться в производительности и внутренностях .NET (многим знакома по инфографике на эти темы), и этот интерес к неочевидным вещам помогает здесь разобраться. Среди того, о чем идет речь в докладе: потоки и задачи, async/await и старый добрый Thread API, стоимость переключения между контекстами потоков и проблема масштабируемости.

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

4: Миграция приложения с MS SQL Server на PostgreSQL

Миграция — это всегда боль: требует времени и сил, чревата багами, отвлекает от создания фич. Как минимизировать эту боль? А как объяснить бизнесу на понятном ему языке, зачем она вообще нужна?

Софт стоит в разы дороже железа — об этом редко кто задумывается, но именно от версии релиза и модели лицензирования зависит стоимость вашего проекта в момент запуска. Например, вы покупаете сервера, и вам необходимо пролицензировать каждое ядро. Стоимость лицензии MS SQL Server каждой железки в итоге будет в 9 раз дороже, чем стоимость самого железа. И разумеется, при масштабировании вы столкнетесь с финансовыми проблемами — лицензии MSSQL Server вылетят в копеечку в отличие от опенсорсных приложений. Но если вы купили релиз Enterprise, то уже вряд ли перейдете на PostgreSQL, потому что достаточно инвестировали в покупку софта.

Все эти моменты важно понимать, чтобы принимать осознанные решения.

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

3: Тайна динамических сборок

Этот «доклад-расследование», которое ведут Игорь «Пуаро» Шаталкин и Георгий «Гастингс» Минашин, можно смотреть не только чтобы применить полученные знания, но и просто как «IT-детектив».

Иногда в процессе работы возникают такие задачки, что голову можно сломать. Вроде бы все нормально, используются стандартные инструменты и практики, а скорость резко падает, что-то начинает тормозить, а модульные тесты прогоняются за 60 минут, вместо 7, как это должно быть по принципам CD. Напрягаем маленькие серые клеточки и… Пуаро и Гастингс по просьбе одного отчаявшегося тимлида берутся за расследование и пытаются выяснить, кто же виноват в медленных тестах.

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

Во время расследования Пуаро демонстрирует основные принципы работы с профайлером, главные особенности библиотек заглушек (Moq, NSubstitute) и тестовых фреймворков (NUnit, xUnit). Он показывает, как создавать динамические типы через Reflection.Emit и как работать с Castle.DynamicProxy.

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

2: A deep dive into a database engine internals

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

Орен Эйни (он же Ayende Rahien) — основатель RavenDB — прямо на ваших глазах открывает этот загадочный ящик, одну за другой вынимает из него блестящие штуки и объясняет, как это работает.

Сначала рассказывает про внутреннюю структуру: как происходит поиск, какие алгоритмы оптимальны в разных ситуациях, как правильно работать с большими значениям. Особое внимание уделяется B+деревьям.

Освещены и транзакции с конкурентностью, и раздражающая всех долговечность (durability) БД. Тут все не так просто. Орен рассказывает, что все, что вы знаете о вводе/ввод — ложь, показывает неочевидное поведение БД из-за медленного ввода/вывода и объясняет, почему диски — отстой.

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

Кстати, а, собственно, почему RavenDB написан на C#, учитывая, что это не самый производительный язык в мире? Ответ дается такой: если писать на более стандартном для баз данных языке, например, С или С++, то издержки и затраты будут огромны, так как предварительно придется проделать кучу всего. В то время как на C# все будет готово в короткий промежуток времени. От идеи до продукта на четвертой версии платформы пройдет всего год. А вообще язык программирования — не ключевой фактор, база данных зависит от множества разных факторов и кусочков (о чем и пойдет речь в докладе).

1: Unlocking performance improvements in .NET

И, наконец, самый понравившийся зрителям доклад.

В последние годы в Microsoft стали уделять производительности .NET больше ресурсов, чем раньше. И о работе в этом направлении рассказывает Стивен Тауб — инженер в Microsoft, который уже много лет занимается платформой .NET и хорошо знает ее изнутри.

Какие изменения с точки зрения производительности произошли за эти годы и почему? В каких случаях удобство использования начинает идти идет вразрез с производительностью? И как разработчикам .NET переломить ситуацию «Быстро, удобно, надежно — выберите два пункта из трех»?

В .NET 5 было уже свыше 250 пулл-реквестов, связанных с производительностью. И каждый новый релиз .NET Framework пытается стать еще лучше. Стивен рассказывает, как — и предлагает присоединяться и вносить вклад в развитие платформы.

Если среди этих докладов вы обнаружили интересные для вас, то и на следующем DotNext такие тоже наверняка найдутся. А смотреть доклады в прямом эфире интереснее: можно и спикеру вопрос задать, и с другими зрителями в чате все обсудить. Конференция пройдет 21-22 октября, на сайте уже можно увидеть описания многих новых докладов, расписание и билеты — там же.

Топ-10 докладов DotNext 2021 Piter