potiuk commented on issue #56635: URL: https://github.com/apache/airflow/issues/56635#issuecomment-3453803970
> This was due to uvicorn not sharing memory between worker, so basically scaling by increasing the number of workers was causing poor resource efficiency. The recommended way now I believe is to scale horizontally by increasing the number of api server pods. Yeah. Re-read https://fastapi.tiangolo.com/deployment/docker/#one-process-per-container. - makes sense. > Yes I think fastapi thread limit is somethwhere around 50, so if can be overloaded quite fast if we have a lot of sync stuff to run. And I guess yes having more workers could help, but on the other hands we have the shared memory problem to solve. I think I agree with Tiangolo on one-process per container in this case - it is much better to manage with K8S without having multiple processes. I think the problem with sync operations running in threads for webserver might happen when they do "actual" work - i.e. cpu-heavy. Which is what blocks GIL - and no matter how many threads you have, they will not run in parallel. Effectively, when we have a long-runinng, CPU-heavy sync operation it basically means "one such request per container (when you have single preocess per container)". Maybe we should look for those? -- 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]
