Рубрика «.net» - 32

Предыстория

Есть у меня маленький и уютный pet-project, который позволяет качать файлы из интернета. Файлы при этом группируются и пользователю отображается не каждый файл, а некоторая группировка. И весь процесс скачивания (и отображение этого процесса) сильно зависел от данных. Данные при этом получались на лету, т.е. пользователь запускает на скачивание и нет никакой информации, сколько придётся качать в реальности.

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

И тут появляется пользователь с логичной проблемой — на большой группировке непонятно, почему прогресс еле ползёт — много файлов надо скачать или низкая скорость? Как я упоминал выше — количество файлов заранее неизвестно. Поэтому, я принял решение добавить счетчик скорости.

Анализ

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

uTorrent DownloadMaster
uTorrent DownloadMaster

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

Итак, нам нужна простая цифра вида 10 MB/s или что-то подобное. Как же нам её посчитать?

Читать полностью »

Предисловие к переводу

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

Введение

Пространство имен System.Threading.Tasks и класс Task впервые были представлены в .NET Framework 4. С тех пор, этот тип, и его производный класс Task<TResult>, прочно вошли в практику программирования на .NET, стали ключевыми аспектами асинхронной модели, реализованной в C# 5, с его async/await. В этой статье я расскажу о новых типах ValueTask/ValueTask<TResult>, которые были введены с целью повышения производительность асинхронного кода, в тех случаях, когда ключевую роль играют накладные расходов при работе с памятью.

ValueTask<TResult> — почему, зачем и как? - 1

Читать полностью »

Наш продукт разрабатывается на платформе .Net Core 2.2 с использованием WCF 4.5 для взаимодействия с SOAP сервисом клиента. В процессе работы сервиса разработчики шины данных заметили высокую нагрузку на сервер. Далее стали появляться проблемы с доступом к сервису. В результате выяснили, что причина кроется в количестве активных соединений.

Существует такая проблема как connection exhaustion. Она может возникать из-за нехватки доступных портов при установлении соединения или ограничения на количество соединений с внешним или внутренним сервисом. Есть два варианта решения:

• Увеличение доступных ресурсов,
• Уменьшение количества соединений.

Первый вариант нам недоступен, так как увеличение ресурсов может производится только на стороне сервис-провайдера. Поэтому решили искать варианты оптимизации количества соединений. В этой статье расскажем о найденном решении.

Реализация пула соединений в WCF для .Net Core с использованием HttpClientFactory - 1
Читать полностью »

История одного монолита. Часть 2 - 1

В прошлой статье я рассказал краткую историю развития внутренних и внешних продуктов компании ДубльГИС. Сегодня погрузимся в детали развития одного из продуктов, а именно экспорта данных. Я расскажу об архитектуре проекта и отдельных технических решениях, которые позволили нам постепенно развивать проект и адаптировать его под меняющиеся с течением времени требования.
Читать полностью »

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

Наша задача звучит очень просто: за два полных дня научить вас всем слоям многопоточки.

CLRium #6: Concurrency & Parallelism. Обучение магии распараллеливания задач - 1

Читать полностью »

Unsafe.AsSpan: Span<T> как замена указателям? - 1

C# — невероятно гибкий язык. На нем можно писать не только бэкэнд или десктопные приложения. Я использую C# для работы, в том числе, и с научными данными, которые накладывают определенные требования на инструменты, доступные в языке. Хотя netcore захватывает повестку дня (учитывая, что после netstandard2.0 большинство фич как языков, так и рантайма, не бэк-портируются в netframework), я продолжаю работать и с легаси-проектами.
В этой статье я рассматриваю одно неочевидное (но, наверное, желаемое?) применение Span<T> и отличие реализации Span<T> в netframework и netcore из-за особенностей clr.

Читать полностью »

Итак, эта история началась с совпадения трёх факторов. Я:

  1. в основном писал на C#;
  2. лишь примерно представлял, как он устроен и работает;
  3. заинтересовался ассемблером.

Эта, на первый взгляд, невинная смесь породила странную идею: а можно ли как-то совместить эти языки? Добавить в C# возможность делать ассемблерные вставки, примерно как в C++.

Если вам интересно, к каким последствиям это привело, — добро пожаловать под кат.

Ассемблерные вставки… в C#? - 1
Читать полностью »

Свой конвертер JSON или ещё немного про ExpressionTrees - 1

Сериализация и десериализация — типичные операции, к которым современный разработчик относится как к тривиальным. Мы общаемся с базами данных, формируем HTTP-запросы, получаем данные через REST API, и часто даже не задумываемся как это работает. Сегодня я предлагаю написать свой сериализатор и десериализатор для JSON, чтобы узнать, что там «под капотом».
Читать полностью »

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

Другой вопрос, что мне субъективно не очень нравится, как объясняется его работа. Потому, предлагаю альтернативный подход, описанный в моей книге, .NET Platform Architecture.

Если мы с вами будем досконально разбираться, почему были выбраны именно эти два алгоритма управления памятью: Sweep и Compact, нам для этого придётся рассматривать десятки алгоритмов управления памятью, которые существуют в мире: начиная обычными словарями, заканчивая очень сложными lock-free структурами. Вместо этого, оставив голову мыслям о полезном, мы просто обоснуем выбор и тем самым поймём, почему выбор был сделан именно таким. Мы более не смотрим в рекламный буклет ракеты-носителя: у нас на руках полный набор документации.

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

На спор: прочитав до конца, вы поймёте, как и почему именно так работает GC - 1

Читать полностью »

Заглянуть «под капот» кода или посмотреть на внутреннее устройство CLR можно с помощью множества инструментов. Этот пост родился из твита, и я должен поблагодарить всех, кто помог составить список подходящих инструментов. Если я пропустил какие-то из них, напишите в комментариях.

Во-первых, я должен упомянуть, что хороший отладчик уже присутствует в Visual Studio и VSCode. Также существует множество хороших (коммерческих) профилировщиков .NET и инструментов мониторинга приложений, на которые стоит взглянуть. Например, недавно я попробовал поработать с Codetrack и был впечатлён его возможностями.

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

Инструментарий для анализа и отладки .NET приложений - 1

Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js