Разобраться раз и навсегда: Task.WhenAll или Parallel.ForEachAsync в C#

Верно. Но речь шла конкретно о сравнении этих двух методов. Я просто прокомментировал о том, что сравнение не правильное.

Разобраться раз и навсегда: Task.WhenAll или Parallel.ForEachAsync в C#

Код начнет работать асинхронно, а значит все таски будут запущенны прежде чем начнется цикл. ConfigureAwait(false) нужен только если присутствует SynchronizationContext, в остальных случаях, после окончания ожидания, цикл продолжится на Thread Pool'е. То есть параллельно.

Разобраться раз и навсегда: Task.WhenAll или Parallel.ForEachAsync в C#

И вообще, скорость это самая не интересная деталь при сравнивании этих двум подходов. Task.WhenAll убьет ваш Thread Pool если после await есть тяжелая CPU операция. Чего не произойдет с Parallel.ForEachAsync. А Parallel.ForEachAsync может бежать последовательно, если вдруг вы бежите с установленными лимитами на CPU (например в k8s).

Разобраться раз и навсегда: Task.WhenAll или Parallel.ForEachAsync в C#

Если хотите параллельности, то нужно добавить await Task.Yield(); перед циклом for

Разобраться раз и навсегда: Task.WhenAll или Parallel.ForEachAsync в C#

А теперь внезапный поворот и все выводы на свалку: TaskWhenAll() в CPU сценарии на самом деле бежит последовательно. ?

Обработка ошибок с помощью IExceptionHandler в ASP.NET Core 8.0

Мне нравится разделение настройки хоста и аппликации. Там все очень четко разделено. В новой настройке через свойства вместо делегатов такая мешанина получается...

Обработка ошибок с помощью IExceptionHandler в ASP.NET Core 8.0

Глупости. Мне нравится.

Обработка ошибок с помощью IExceptionHandler в ASP.NET Core 8.0

Никто не отменял

«Выгорел просто в угли и уволился» — истории карьерных неуспехов, часть 5

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

Архитектурные антипаттерны в микросервисах и способы их избежания

Половина из этого не имеет отношения ни к патернам, ни к анти патернам. Просто ошибки и недочеты проектирования микросервисов.

Преимущества функционального программирования на примерах C#

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

Высокомодульный и многократно используемый фрагмент кода ?

Адаптируем код .NET Core под Linux

Не переводите больше ничего, пожалуйста. Никогда.

Топ 10 самых распространенных ошибок в использовании юнит-тестов

 Я в своей команде когда-то даже название для него придумал: "Poor man DI" :))

Это не ты, это Mark Seemann придумал.

GraphQL: от восторга до разочарования

5.2. Более качественный инструментарий, за исключением Google Chrome

Просто добавляйте ?operation=xxx к url. Например /graphql?operation=getUser

5.4. Мониторинг

application/graphql-response+json в помощь. https://github.com/graphql/graphql-over-http/blob/main/spec/GraphQLOverHTTP.md#applicationgraphql-responsejson

Введение в GraphQL для .NET-разработчиков: мутация

однако GraphQL .NET больше не мейнтейнится

Что за чушь? Живее всех живых. Просто посмотрите на странице релизов, коммитов и пулл реквестов. Недавно там была добавлена поддержка AOT, сейчас работают на добавлением OpenTelemetry и Federation2. Разница лишь в том, что эти ребята спокойно делают свою работу. Чисто и красиво. А Hot Chocolate бегают с якрими колпаками на голове, машут руками, всячески пытаясь привлешь внимание и клянчат звездочки на github.

Testcontainers: тестирование с реальными зависимостями

Это в Java, а .NET такого нету. Но и в Java, как я понимаю, реализация не полноценная. Если код меняется в зависимости от конфигурации, то этим нельзя пользоваться.

Testcontainers: тестирование с реальными зависимостями

2.5 года назад написал свою библиотеку для тех же целей на .NET и она очень успешно используется в нашей фирме. Она не такая гибкая, но достаточно легко расширяется. Тестим MySql, MongoDB, Postgress, RabbitMq, Kafka+Zookeeper, Elasticsearch (включая cross-cluster). Почитал, подумал, а может заменить на TestContainers? Но два самых важных фичера там не вижу:

1) reuse containers: там нельзя оставить в живых контейнер после теста, чтобы следующий тест бежал быстрее, а не тратил время на новый docker run + wait for readiness. У нас же есть две конфигурации Dev и CI. В Dev контейнер остается в живых и может быть использован заново. В CI тесты бегут параллельно, поэтому каждый раз поднимается новый контейнер и умирает после теста (или нескольких тестов).

2) executor: когда тестов много, они жрут много ресурсов, и много CI бегут параллельно, Docker Host не выдерживает и это сильно замедляет процесс CI/CD. А вот kubernetes решает эту проблему. У нас можно выбрать в качестве executor'а Docker или kubernetes.

Вот когда, и если вообще, эти возможности будут добавлены, наверное гляну снова. Ну а пока, работает - не трогай.

История о том, как мы монолит с .NET Framework на .NET 6 и Kubernetes переводили

Нет, не предлогаю. Я предлогаю давать возможность использавть новые фичи в новом коде старых проектов. Делайвыводыправильно.

История о том, как мы монолит с .NET Framework на .NET 6 и Kubernetes переводили

IMHO, переходить надо на все major версии сразу. Во-первых, улучшения производительности происходят в каждой версии. Во-вторых, новые фичи всегда сладки, работа с новешими технологиями помогает удержать разработчиков. В-третьих, гораздо проще изучить список breaking changes раз в год, чем два списка раз в два года.

gRPC в .NET — рецепты счастья

но он требует SSL

Это не обязательно, хотя и приветствуется:

If an HTTP/2 endpoint is configured without TLS, the endpoint's ListenOptions.Protocols must be set to HttpProtocols.Http2. An endpoint with multiple protocols (for example, HttpProtocols.Http1AndHttp2) can't be used without TLS because there's no negotiation. All connections to the unsecured endpoint default to HTTP/1.1, and gRPC calls fail.

Если настроить сервер на Http2 only то можно и без TLS

.ConfigureWebHostDefaults(webBuilder =>
{
    webBuilder.UseStartup<Startup>();
    webBuilder.ConfigureKestrel(options =>
    {
        options.ConfigureEndpointDefaults(listenOptions =>
        {
            listenOptions.Protocols = HttpProtocols.Http2;
        });
    });
})