Я не говорил, что так правильно. Я говорил, что так будет честно сравнивать. Ведь вопрос стоял в способах запараллелить асинхронные операции, поэтому нужно убедиться, что они действительно асинхронные и действительно параллелятся. А то что планировщик много потоков не выделит, это как раз и есть та разница которая влияет на "производительность" этих двух подходов.
Код начнет работать асинхронно, а значит все таски будут запущенны прежде чем начнется цикл. ConfigureAwait(false) нужен только если присутствует SynchronizationContext, в остальных случаях, после окончания ожидания, цикл продолжится на Thread Pool'е. То есть параллельно.
И вообще, скорость это самая не интересная деталь при сравнивании этих двум подходов. Task.WhenAll убьет ваш Thread Pool если после await есть тяжелая CPU операция. Чего не произойдет с Parallel.ForEachAsync. А Parallel.ForEachAsync может бежать последовательно, если вдруг вы бежите с установленными лимитами на CPU (например в k8s).
Мне нравится разделение настройки хоста и аппликации. Там все очень четко разделено. В новой настройке через свойства вместо делегатов такая мешанина получается...
Есть люди которые хотят в IT любой ценой. Но если для вас это просто профессия, а не призвание - страдать вам там до полного выгорания. Программировать нужно любить, иначе ваша история будет в слудующем выпуске.
Что за чушь? Живее всех живых. Просто посмотрите на странице релизов, коммитов и пулл реквестов. Недавно там была добавлена поддержка AOT, сейчас работают на добавлением OpenTelemetry и Federation2. Разница лишь в том, что эти ребята спокойно делают свою работу. Чисто и красиво. А Hot Chocolate бегают с якрими колпаками на голове, машут руками, всячески пытаясь привлешь внимание и клянчат звездочки на github.
Это в Java, а .NET такого нету. Но и в Java, как я понимаю, реализация не полноценная. Если код меняется в зависимости от конфигурации, то этим нельзя пользоваться.
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.
Вот когда, и если вообще, эти возможности будут добавлены, наверное гляну снова. Ну а пока, работает - не трогай.
Я тоже иногда наберу в чайник воды и стою жду пока закипит. А через 10 минут
приходит @Onexkkaи говорит дедлокя замечаю, что не включил его.Я не говорил, что так правильно. Я говорил, что так будет честно сравнивать. Ведь вопрос стоял в способах запараллелить асинхронные операции, поэтому нужно убедиться, что они действительно асинхронные и действительно параллелятся. А то что планировщик много потоков не выделит, это как раз и есть та разница которая влияет на "производительность" этих двух подходов.
Верно. Но речь шла конкретно о сравнении этих двух методов. Я просто прокомментировал о том, что сравнение не правильное.
Код начнет работать асинхронно, а значит все таски будут запущенны прежде чем начнется цикл.
ConfigureAwait(false)нужен только если присутствуетSynchronizationContext, в остальных случаях, после окончания ожидания, цикл продолжится на Thread Pool'е. То есть параллельно.И вообще, скорость это самая не интересная деталь при сравнивании этих двум подходов.
Task.WhenAllубьет ваш Thread Pool если послеawaitесть тяжелая CPU операция. Чего не произойдет сParallel.ForEachAsync. АParallel.ForEachAsyncможет бежать последовательно, если вдруг вы бежите с установленными лимитами на CPU (например в k8s).Если хотите параллельности, то нужно добавить await
Task.Yield();перед цикломforА теперь внезапный поворот и все выводы на свалку:
TaskWhenAll()в CPU сценарии на самом деле бежит последовательно. ?Мне нравится разделение настройки хоста и аппликации. Там все очень четко разделено. В новой настройке через свойства вместо делегатов такая мешанина получается...
Глупости. Мне нравится.
Никто не отменял
Есть люди которые хотят в IT любой ценой. Но если для вас это просто профессия, а не призвание - страдать вам там до полного выгорания. Программировать нужно любить, иначе ваша история будет в слудующем выпуске.
Половина из этого не имеет отношения ни к патернам, ни к анти патернам. Просто ошибки и недочеты проектирования микросервисов.
Высокомодульный и многократно используемый фрагмент кода ?
Не переводите больше ничего, пожалуйста. Никогда.
Это не ты, это Mark Seemann придумал.
5.2. Более качественный инструментарий, за исключением Google Chrome
Просто добавляйте
?operation=xxxк url. Например/graphql?operation=getUser5.4. Мониторинг
application/graphql-response+jsonв помощь. https://github.com/graphql/graphql-over-http/blob/main/spec/GraphQLOverHTTP.md#applicationgraphql-responsejsonЧто за чушь? Живее всех живых. Просто посмотрите на странице релизов, коммитов и пулл реквестов. Недавно там была добавлена поддержка AOT, сейчас работают на добавлением OpenTelemetry и Federation2. Разница лишь в том, что эти ребята спокойно делают свою работу. Чисто и красиво. А Hot Chocolate бегают с якрими колпаками на голове, машут руками, всячески пытаясь привлешь внимание и клянчат звездочки на github.
Это в Java, а .NET такого нету. Но и в Java, как я понимаю, реализация не полноценная. Если код меняется в зависимости от конфигурации, то этим нельзя пользоваться.
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.
Вот когда, и если вообще, эти возможности будут добавлены, наверное гляну снова. Ну а пока, работает - не трогай.
Нет, не предлогаю. Я предлогаю давать возможность использавть новые фичи в новом коде старых проектов. Делайвыводыправильно.