omkar-foss commented on PR #43797:
URL: https://github.com/apache/airflow/pull/43797#issuecomment-2464367518
Hey @dolfinus, yes, the throughput in this case would be very similar for
both snippets, because when calling `asyncio.to_thread()` (executor
unspecified), the default thread pool executor will be used and be subject to
same 40 thread limit. But unlike sync functions where entire request is
processed in a thread, in async we'll have control over what should be
processed in a separate thread.
Example: As our new APIs have a mix of CPU-bound (e.g. common params
resolution, data checks, Pydantic validations, etc.) and IO-bound (e.g. DB
queries, network calls) activities, I guess we could tune it something like
this:
```python
@route.get(...)
async def handler(...):
# CPU bound
if some_check:
raise HTTPException(status.HTTP_404_NOT_FOUND, "Not Found")
# IO bound, sent to it's own thread
something = await asyncio.to_thread(session.get, ...)
# CPU bound again
return SomePydanticModel(something)
```
We could alternatively use `run_in_threadpool` instead of
`asyncio.to_thread` which is provided by FastAPI, [example
here](https://github.com/fastapi/fastapi/issues/1066#issuecomment-612940187).
Either way we go, it'll need thorough testing to understand what's working for
us in terms of performance! :)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
