I huge chunk of legacy sync code ( a huge function which calls other sync functions, includes sync http API calls with requests
library, and so on ). This function is run as a part of a Queue worker (picks up tasks from the queue and executes this function )
Facing performance issues and moving to async function seemed as a way out.
To save on time and avoid converting every single function to async def, I used anyio.to_thread.run_sync
.Performance looked great until it broke midway(works 9/10 times ) without any errors being thrown. The Queue worker times out with no errors caught.
Im planning to move to https://dev.to/0xbf/turn-sync-function-to-async-python-tips-58nn asyncio (although I dont expect much since anyio already uses asyncio as a backend), ..
But help me understand this. How is converting a sync function to run in a thread speeding up my worker? Will the GIL not block the main thread when the new thread is run to completion? Or perhaps when the second thread is idle doing I/O, it gets context switched with the main thread?
As for my concrete problem, I believe its happening because of the increasing number of total threads in the system. Is it fair to assume so since I've just assigned 0.25vCPU to the worker container? Also, are threads CPU intensive or memory intensive? In the context of python(GIL), it doesnt make sense to have threads for a CPU intensive workload right? Does it mean more threads implies more load on memory and not on CPU per se?