![](https://habrastorage.org/webt/66/nz/te/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, чтобы не делать бесполезную работу.
![](https://habrastorage.org/getpro/habr/upload_files/562/bad/ee5/562badee5fd255e65df4414a4156c251.png)
Решение, которое было предложено разработчиками Mongo, команду Станислава не устроило. На примере приложения, состоящего из 70 микросервисов, Станислав рассказывает, как его команда достигла пятикратного ускорения оригинального драйвера MongoDB и что сделала для этого.
7: Debugging one layer deeper
Кевин Госсе уже выступал на DotNext на тему отладки (например, в докладе «Debugging asynchronous scenarios in .NET»). Но в этот раз он предлагает спуститься на уровень ниже обычного.
Обычно при отладке мы видим написанный нами код и, как правило, знаем, что с ним делать. Но это лишь первый уровень.
Следующий уровень уровень — это когда причины кроются в BCL, стандартной библиотеке .NET. Здесь посложнее, потому что исходного кода в вашей IDE нет. Но его можно найти в репозитории .NET Core, так что даже в такой ситуации вы не выходите за рамки комфортного .NET-мира.
Однако бывают и ситуации, когда вы вынуждены выйти из зоны комфорта, погрузиться в среду выполнения и попробовать разобраться с С++, ассемблером и другими страшными штуками.
![](https://habrastorage.org/getpro/habr/upload_files/a27/04e/88c/a2704e88c68394b94f96bef66bc2fb36.png)
Сам Кевин занимается разработкой трейсера 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. Следить за ходом рассуждений и исследований очень интересно, но как сказал сам Федерико, проводить реальные измерения эпидемического поведения сложно.
![](https://habrastorage.org/getpro/habr/upload_files/54f/231/a6e/54f231a6edae819731f3fcc0e3faa3fa.png)
В итоге заезженная тема коронавируса становится намного интересней, если взглянуть на нее под другим углом — исследовательским. Тогда она превращается в работу с данными, создание моделей и гипотез, формулы и уравнения.
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 много продвинутых возможностей, которые не так-то просто реализовать самостоятельно.
![](https://habrastorage.org/getpro/habr/upload_files/537/f57/771/537f577717279f012eab167455d22fa9.png)
Во время расследования Пуаро демонстрирует основные принципы работы с профайлером, главные особенности библиотек заглушек (Moq, NSubstitute) и тестовых фреймворков (NUnit, xUnit). Он показывает, как создавать динамические типы через Reflection.Emit и как работать с Castle.DynamicProxy.
В результате расследования сыщики выявят причины, потенциально уязвимые места, предложат решение, а зрители смогут взять на вооружение методологию расследования и проводить свои следственные мероприятия.
2: A deep dive into a database engine internals
База данных — черный ящик, внутри которого происходит непонятная магия. По крайней мере, так думают большинство людей, даже свеженькие выпускники вузов, голова которых забита теоретической информацией.
Орен Эйни (он же Ayende Rahien) — основатель RavenDB — прямо на ваших глазах открывает этот загадочный ящик, одну за другой вынимает из него блестящие штуки и объясняет, как это работает.
Сначала рассказывает про внутреннюю структуру: как происходит поиск, какие алгоритмы оптимальны в разных ситуациях, как правильно работать с большими значениям. Особое внимание уделяется B+деревьям.
Освещены и транзакции с конкурентностью, и раздражающая всех долговечность (durability) БД. Тут все не так просто. Орен рассказывает, что все, что вы знаете о вводе/ввод — ложь, показывает неочевидное поведение БД из-за медленного ввода/вывода и объясняет, почему диски — отстой.
![](https://habrastorage.org/getpro/habr/upload_files/d6b/f45/bc4/d6bf45bc4bb8f1a047a62128e32f7f40.png)
И, наконец, есть различные трюки, к которым приходится прибегать с целью оптимизации — рассматриваются компромиссы масштаба и вычислений.
Кстати, а, собственно, почему RavenDB написан на C#, учитывая, что это не самый производительный язык в мире? Ответ дается такой: если писать на более стандартном для баз данных языке, например, С или С++, то издержки и затраты будут огромны, так как предварительно придется проделать кучу всего. В то время как на C# все будет готово в короткий промежуток времени. От идеи до продукта на четвертой версии платформы пройдет всего год. А вообще язык программирования — не ключевой фактор, база данных зависит от множества разных факторов и кусочков (о чем и пойдет речь в докладе).
1: Unlocking performance improvements in .NET
И, наконец, самый понравившийся зрителям доклад.
В последние годы в Microsoft стали уделять производительности .NET больше ресурсов, чем раньше. И о работе в этом направлении рассказывает Стивен Тауб — инженер в Microsoft, который уже много лет занимается платформой .NET и хорошо знает ее изнутри.
Какие изменения с точки зрения производительности произошли за эти годы и почему? В каких случаях удобство использования начинает идти идет вразрез с производительностью? И как разработчикам .NET переломить ситуацию «Быстро, удобно, надежно — выберите два пункта из трех»?
В .NET 5 было уже свыше 250 пулл-реквестов, связанных с производительностью. И каждый новый релиз .NET Framework пытается стать еще лучше. Стивен рассказывает, как — и предлагает присоединяться и вносить вклад в развитие платформы.
Если среди этих докладов вы обнаружили интересные для вас, то и на следующем DotNext такие тоже наверняка найдутся. А смотреть доклады в прямом эфире интереснее: можно и спикеру вопрос задать, и с другими зрителями в чате все обсудить. Конференция пройдет 21-22 октября, на сайте уже можно увидеть описания многих новых докладов, расписание и билеты — там же.