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

66nztejnyw9fucjciro0y0xdnv0.jpeg

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Какой процент планируемого к оптимизации кода будет работать в конечном сервисе?

  • Как он повлияет на систему?

  • Какой процент времени освободит?

  • Убедиться, что проблема не в железе

  • Что недозагружено? Что перегружено? Сеть, процессор?

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

image-loader.svg

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

7: Debugging one layer deeper

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

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

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

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

image-loader.svg

Сам Кевин занимается разработкой трейсера 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. Следить за ходом рассуждений и исследований очень интересно, но как сказал сам Федерико, проводить реальные измерения эпидемического поведения сложно.

image-loader.svg

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

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 много продвинутых возможностей, которые не так-то просто реализовать самостоятельно.

image-loader.svg

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

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

2: A deep dive into a database engine internals

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

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

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

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

image-loader.svg

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

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

1: Unlocking performance improvements in .NET

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

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

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

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

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

© Habrahabr.ru