.NET Parallel.ForEachAsync Can Serialize in Single-CPU Containers

Performance Impact of CPU Limits

Testing revealed that a .NET Parallel.ForEachAsync loop processing 200 records took 42.1 seconds in a container with two CPU cores. When the container's CPU limit was reduced to one core, the processing time nearly doubled to 83.6 seconds. This slowdown can be difficult to detect without a performance baseline, as the batch still completes successfully.

Default Concurrency Behavior

The Parallel.ForEachAsync method, when used without explicit ParallelOptions or with default options, limits concurrent operations to Environment.ProcessorCount. Since .NET 6, on Linux, macOS, and Windows, Environment.ProcessorCount reports the container's CPU utilization limit, rounded up. Consequently, a container with a one-CPU limit will report 1, causing the parallel loop to execute only one operation at a time, even for I/O-bound tasks that do not consume CPU during waits.

Overlooking Default Settings

Developers might inadvertently rely on the default concurrency by passing only a CancellationToken in ParallelOptions, which leaves MaxDegreeOfParallelism at its default value of -1. This still defers to Environment.ProcessorCount, effectively serializing I/O-bound asynchronous operations in single-CPU environments. Other runtimes like Go and JVM handle container CPU limits for their default concurrency settings, but the specific issue here is how .NET translates a CPU-derived value into an I/O concurrency limit.

Managing Asynchronous Workloads

Asynchronous operations often spend significant time waiting for external services, not consuming CPU. The number of concurrent operations needed depends on desired throughput and individual operation latency. To prevent serialization in CPU-limited containers, developers must explicitly set ParallelOptions.MaxDegreeOfParallelism to a value appropriate for the workload, rather than relying on the default derived from Environment.ProcessorCount.