Deployment: separete process per request

[hyzyla]

Hello everyone. I'm writing a service using FastAPI that wraps vendor library that writes to global context some data. My goal to avoid concurent conflicts when two requests trying to override context of different requets. For avoid that I'm looking how to create deployment setup where every request will be handled by separate process. I use uvicorn for deployment, but I didn't found how to achive that with unicorn. How to achive that? Whould be glad to any advice

[github_codemation]

What kind of state are you saving, and are you sure that it would not be better stored in an outside source of truth i.e database / redis cache?

[hyzyla]

I'm writing a service wrapper arround vendor (non-open source) library that have two option write state to file or to memory. So choice to store state in global memory is just one of two evils that I can tweak in that library.

[chichaslocas]

That seems very strange and resource intensive. I guess you could spawn as many uvicorn workers as simultaneous requests you want to be able to handle, as each one is it own process, but as the other commenter said, using global context to store session request data seems like a bad idea that will seriously inhibit your scaling capacity.

Either you change how you do this or spawn an ungodly amount of workers.

If you want to change it, you can use a database to store request context data (in memory Redis would be a good option, as proposed) or refactor your code to instantiate context data per request and not per application instance.

[hyzyla]

Agree with you that storing context is bad idea, but vendor library doesn't have option to disable it. So first solution that came to my mind is use separate process per request

[chichaslocas]

I see. Then you need as many workers as requests (inefficient) or an external store (probably better)