uwsgi-docs | Official uWSGI docs , examples , tutorials , tips and tricks | Learning library

First of all, the number of cores is not necessarily the number of processors. On early computers days it was like 1-1, but with modern improvements one processor can offer more than one core. (Check this: https://www.tomshardware.com/news/cpu-core-definition,37658.html). So, if it detected 12 cores, you can use it as the basis for your calculus.

The number of processes means how many different parallel instances of your web application will be running in that server. WSGI first creates a master process that will coordinate things. Then it bootstraps your application and creates N clones of it (fork). These child forked processes are isolated, they don't share resources. If one process get's unhealthy for any reason (e.g. I/O problems), it can terminate or even be voluntarily killed by the master process while the rest of the clones keep working, so your application is still up and running. When a process is terminated/killed the master process can create another fresh clone to replace it (re-spawn).

It is OK to set the number of processes as a ratio of the available cores. But there's no benefit of increasing it too much. So, you definitely shouldn't set it to the limit (2784). Remember that the operating system will round-robin across all processes to give each one a chance of have some instructions processed. So, if it offers 12 cores and you create like 1000 different processes, you are just putting stress on the system and you'll end up getting the same throughput (or even a worse throughput since there's so much chaos).

Then we move on to the number of threads. For the sake of simplicity, let's just say that the number of threads means the number of parallel requests each of these child process can handle. While one thread is waiting for a database response to answer a request, another thread could be doing something else to answer another request.

You may say: why do I need multiple threads if I already have multiple processes?

A process is an expensive thing, but threads are just the way you can parallel the workload a process can handle. Imagine that a process is a Coffee Shop, and threads are the number of attendants you have inside. You can spread 10 different Coffee Shops units around the city. If one of them closes, there's still another 9 somewhere else the customer can go. But each shop need an amount of attendants to serve people the best way possible.

If you set just a single process with 100 threads, that means that 100 is your concurrency limit. If at some point there's 101 concurrent requests to your application, that last one will have to wait for one of the 100 first to be finished. That's when you start to get an increasing response time for some users. The more the requests are queued, the worse it gets (queuing theory).

Besides that, since you have a single process, if it crashes, all these 100 requests will fail with a server error (500). So, it's wiser to have more processes, let's say 4 processes handling 25 threads each one. You still have the 100 concurrency limit, but your application is more resilient.

It's up to you to get to know your application expected load so you can adjust these numbers properly. When you have external integrations like databases, you have to consider it's limitations also. Let's say a PostgreSQL Server that can handle 100 simultaneous connections. If you have 10 WSGI processes, 40 threads each (with a connection pool of size 40 as well), then there's the possibility that you stress the database with 400 connections, and then you have a big problem, but that's not your case!

So, just use the suggested number of processes (12 * 2 = 24) and set as much threads as needed to offer a certain desired level of concurrency.

If you don't know the expected load, I suggest you to make some sort of performance test that can simulate requests to your application and then you can experiment different loads and settings and check for it's side effects.

If you are running your application in a container orchestration platform, like Kubernetes, then you can probably have multiple balanced containers serving the same application. You can even make it dynamic so that the number of containers increases if memory or processing go beyond a threshold. That means that on top of all those WSGI fine tuning for a single server, there's also other modern layers of configurations that can help you face peaks and high load scenarios.

All I know about uWSGI is that it exists, but I noticed a mistake here:

In general, uwsgi_params is already shipped with your Nginx, so all you need is include uwsgi_params (so it refers to /etc/nginx/uwsgi_params or similar).

If that is not the case, you will likely also need to give Nginx enough permissions to read the directory structure that file is in, not just the file itself.

True - if someone wants it badly enough, the only way to truly secure your algorithms is not to hand them out. But, reality is that code is hard to understand anyway. Often, just not documenting code is enough to discourage. There are some techniques, however, and your effort varies with how secure they are. Some approaches that come to mind are.

• Compile to bytecode: I've seen it done in the wild, there was company that made a Python email client for Linux / Outlook. I recall that it was obfuscated through a compiled distribution. You'd have to research the proper tool.

• Obfuscate at a per-script level: Check out the pyminifier tool. It can make your scripts pretty near impossible to read (but it can be reversed with reasonable effort)

• Use an advanced obfuscator: Look at pyarmor. It is a lot more complex and will be harder to implement -- but it looks like it would get the job done.

• Open source it. Seems counter intuitive -- but algorithms are rarely the most valuable aspect of code. Having the skill, time, resources to understand and maintain it is. It is very likely that it doesn't matter if anyone sees your code. If you are giving a good service to your customer, they generally have much better things to do than to take on your code base. There are plenty of enterprise companies making a living from open source software (eg. Startburst, 2nd Quadrant.)

(Example code obfuscated using pyminifier)

Yeah I ran into the same problem, debugging for hours why spare2 was behaving exactly like spare would, without noticing the log line saying that spare2 was unavailable.

Anyway, yes, the PyPI version of uwsgi is 2.0.x while the documentation and github code in master are 2.1.x. From what I'm reading, this difference has been around for quite some time.

The author of spare2 kindly backported the plugin to 2.0.x: https://github.com/KLab/uwsgi-cheaper-spare2.

I'm inclined to use the built-in busyness, but then, in 2.1.x the situation will reverse: spare2 is built-in and busyness is plug-in.

Solved the issue by placing the project to /tmp directory.

nginx being run from www-data user was not able to access the internal directory MySite and thus the socket or the files placed there, despite being assigned to the user www-data.

Now, my other question is regarding the cause of permission issue for nginx, despite providing the the uid and gid of the directory to www-data, what could have been the issue?

Note: My user named ubuntu is a sudoer.

You may need to run commmand python manage.py collectstatic from the shell of your platform if you are using heroku here i the command

For running flask, you do not need nginx, just a webserver of your choice, but life with nginx is just easier. If you are using Apache, you want to consider to use a WSGI.

I remember reading somewhere in the Flask documentation what is stated by an answer to "Are a WSGI server and HTTP server required to serve a Flask app?" as

The answer is similar for "should I use a web server". WSGI servers happen to have HTTP servers but they will not be as good as a dedicated production HTTP server (Nginx, Apache, etc.).

The main idea behind is the architectural principle of splitting layers to ease debugging and increase security, similarly to the concept that you split content and structure (HTML & CSS, UI vs. API):

• For the lower layers, see e.g. https://en.wikipedia.org/wiki/Transport_layer Having a dedicated HTTP server allows you to do package-filtering etc. on that level.
• The WSGI is the interface layer between the webserver and the webframework.

I have seen clients only running a WSGI server alone, with integrated HTTP support. Using an additional webserver and/ or proxy is just good practice, but IMHO not strictly necessary.

• https://flask.palletsprojects.com/en/1.1.x/deploying/mod_wsgi/ describes the Apache way for flask
• https://flask.palletsprojects.com/en/1.1.x/tutorial/deploy/ elaborates on how a production environment should look like
• Deploying Python web app (Flask) in Windows Server (IIS) using FastCGI
• Debugging a Flask app running in Gunicorn
• Flask at first run: Do not use the development server in a production environment

Turns out default values are indicated in help when they exist and can be accessed through uwsgi --help | grep 'default' which yields a list with e.g. things like