With gunicorn, yes, 5 workers = 5 processes but internally I'm not sure what it's actually called. Unlike threads these things start immediately. I.e. they are spawned straight away. Perhaps on an operating system level they are threads.
I don't know why the Postgres wasn't able to create and commit rows in concurrency.
Thanks for dong the benchmark.
- When you said 5 workers for gunicorn or uwsgi, was that 5 processes or 5 threads in a single process?
- if it takes 0.02 sec to create a single session, shouldn't it be able to process more than 50 req per sec since sessions would be created concurrently. The only way that the 50 req/sec becomes the limit is if everything is being serialized in a single thread. Yet that appears to be what happened. Can you shed some light on that?
Thanks.
Comment
With gunicorn, yes, 5 workers = 5 processes but internally I'm not sure what it's actually called. Unlike threads these things start immediately. I.e. they are spawned straight away. Perhaps on an operating system level they are threads.
I don't know why the Postgres wasn't able to create and commit rows in concurrency.
Parent comment
Thanks for dong the benchmark. - When you said 5 workers for gunicorn or uwsgi, was that 5 processes or 5 threads in a single process? - if it takes 0.02 sec to create a single session, shouldn't it be able to process more than 50 req per sec since sessions would be created concurrently. The only way that the 50 req/sec becomes the limit is if everything is being serialized in a single thread. Yet that appears to be what happened. Can you shed some light on that? Thanks.