Investigate Python SDK concurrency limitations

[sicoyle]

The Python Dapr SDK currently relies on threadpool-based execution for workflow and activity processing. This model has known limitations:

• The GIL (Global Interpreter Lock) constrains true parallelism for CPU-bound work
• Thread pool exhaustion under high concurrency can delay sidecar acknowledgments

Native asyncio execution would allow the SDK to handle a higher volume of concurrent workflow tasks without the overhead and contention introduced by thread management, reducing sidecar response latency under sustained load.

Goals

• Quantify the throughput and latency characteristics of the current threadpool implementation under sustained workflow load
• Rewrite workflow and activity execution to use native asyncio
• Validate that the rewrite improves sidecar response latency and throughput under load conditions

Tasks

• Benchmark current threadpool implementation — measure workflow throughput, activity concurrency, and sidecar acknowledgment latency under sustained load
• Document failure conditions — identify load thresholds at which sidecar response times begin to degrade
• Design asyncio execution model — propose the replacement architecture for workflow and activity dispatch
• Implement asyncio rewrite — replace threadpool-based execution with native asyncio in the workflow worker
• Ensure existing workflow and activity behavior is preserved
• Load validate — re-run benchmarks against the rewritten implementation under production-representative load and confirm improvement in sidecar response latency and throughput
• Document operational guidance — update SDK documentation with concurrency configuration recommendations for workflow-heavy deployments
• Write Dapr OSS blog on findings