uvicorn | 🦄 | Reactive Programming library

Unless you have enabled CPU is always allocated, background threads and processes might stop receiving CPU time after all HTTP requests return. This means background threads and processes can fail, connections can timeout, etc. I cannot think of any benefits to running background workers with Cloud Run except when setting the --cpu-no-throttling flag. Cloud Run instances that are not processing requests, can be terminated.

Signal 6 means abort which terminates processes. This probably means your container is being terminated due to a lack of requests to process.

Run more workloads on Cloud Run with new CPU allocation controls

What if my application is doing background work outside of request processing?

Run a subprocess to return a redirect response from one port to another.

main.py:

It's all note : when you use function get_db_session in database.py like a generator, close function of session doesn't work as auto, so you should close them like manually. If you need more detail, send email, drr000t3r@gmail.com. Good Luck.

database.py

When running the gunicorn command, you can try to add workers parameter with using options -w or --workers.

It defaults to 1 as stated in the gunicorn documentation. You may want to try to increase that value.

Example usage:

First you should rename requierements.txt (there is an extra 'e' in filename) to requirements.txt. Because "Heroku automatically recognizes your app as a Python app if it includes a requirements.txt, setup.py or Pipfile file in its root directory." (*)

And then you should add uvicorn into your requirements.txt.

If you're not raising an HTTPException then normally any other uncaught exception will generate a 500 response (an Internal Server Error). If your intent is to respond with some other custom error message and HTTP status when raising a particular exception - say, ValueError - then you can use add a global exception handler to your app:

You need to add new location to serve your websocket resources in nginx configuration. Change your consumer route to something like /ws/updates.

I will quote the answer from here, I think it might be useful. All credit to q210.

In our case, the root cause was that ipvs, used by swarm to route packets, have default expiration time for idle connections set to 900 seconds. So if connection had no activity for more than 15 minutes, ipvs broke it. 900 seconds is significantly less than default linux tcp keepalive setting (7200 seconds) used by most of the services that can send keepalive tcp packets to keep connections from going idle.

The same problem is described here moby/moby#31208

To fix this we had to set the following in postgresql.conf:

Thanks to your last comment I understood better your question.

Your real question

So in fact your question is why is FastAPI object is created 3 times.

In the log one can indeed see that you have 3 different memory adresses 0x102b35d50, 0x10daadf50, 0x1106bfe50

This doesn't mean that you have 3 workers, just that the FastAPI object is created 3 times. The last one this the one that your API will use.

Why it happens

The object is created multiple times, because :

1. First, you run main.py that go through the all code (one creation of FastAPI object), and then reach the __main__
2. Then uvicorn launch main:app so it go once again to the file main.py and build another FastAPI object.
3. The last one is created by the debug=True when you set it to False you have one less FastAPI object created. I'm not quite sure why.

The solution

The solution is to separate the API definition from the start of the API.

For example, one could create a run.py file with :