0đź‘Ť
As far as I can see, there are only 2 cores. You cannot span a massive amount of processes and threads over just two cores. You’ll get advantages if your threads have to wait for other IO processes. Then they go to sleep and others can work.
Always max two (=number of cores) at the same time.
You do not provide much information about your app except that it’s “mostly simple read, but we expect lot of hits”. This is not the sound of a lot of IO waits.
I guess the database is running on the same host as well (will need some CPU time as well)
Try to lower your threads/processes to 4 at first. Then play around with +/- 1 and test accordingly.
Read https://uwsgi-docs.readthedocs.io/en/latest/ThingsToKnow.html
You’ll find sentences like:
There is no magic rule for setting the number of processes or threads
to use. It is very much application and system dependent.By default the Python plugin does not initialize the GIL. This means
your app-generated threads will not run. If you need threads, remember
to enable them with enable-threads. Running uWSGI in multithreading
mode (with the threads options) will automatically enable threading
support. This “strange” default behaviour is for performance reasons,
no shame in that.
0đź‘Ť
If you have enough money change your processor according to your motherboard requirements. Better go for core i3 or above.
This is because you have only two core processor which is easily got hotted when you run a multi-thread software. You can,t make very task on it. Sometimes it runs so fast and then stopped some massive multi-thread software.
- [Django]-RabbitMQ keeps connections running for a long time
- [Django]-Url contains spaces in django v3
- [Django]-Using Django with MySQL for storing and looking up Large DNA Microarray Results
- [Django]-How to have nested url namespaces with a dynamic first part in Django
- [Django]-Looking for read-write lock in Django using PostgreSQL, e.g., SELECT FOR SHARE