4 ms·

Why the need for these "how to configure" this and that when it can be as simple as runthisnowdamnit.py using gunicorn or cherrypy? Or you know, some other serv

Why the need for these "how to configure" this and that when it can be as simple as runthisnowdamnit.py using gunicorn or cherrypy? Or you know, some other server which doesnt require learning and blogging about its configuration and various options it can be set up? Sure that might come in handy, when or rather if you ever face millions of users/load problems. Wasnt the point of a web application framework that you could put it anywhere and type run and have it done, instead of having to think of process- or event- or thread- based serving and static files? Thats not python. Even php is simpler/better in this regard. Its not so difficult to run an instance of a threaded/process/eventlet server and let your app do the work.

gardentheory 15y ago
Well i think the gist is that serving files and running applications have different resource requirements. Therefore it is common to have a proxy serve statics and proxy in addition to an application server running python. The advantage with uwsgi as i understand it is that the proxy protocol is faster than http.
- unbit 15y ago
  No, uWSGI has nothing to do with performance. Its strength is in the features and operational modes. Each application is diferent from the others and (could) requires specific tuning. This is the spirit of the project, that is at the opposite of solutions like gunicorn. There is no "best choice", it depends on how you approach to system administration/development. Saying uWSGI is better than gunicorn (or the opposite) is like comparing bananas with oranges.
  - gardentheory 15y ago
    I have only used apache as an application server with mod wsgi behind nginx. I have not used gunicorn or uwsgi. Yhanks for the correction, I should have just stopped my explanation before that.
unbit 15y ago
in both gunicorn and php you have to choose the number of workers/processes. Most of the time (unless you use php-fastcgi) the number of php processes is choosen by the sysadmin as it maps 1:1 with apache processes. The same is true for mod_wsgi. There is always some form of configuration independently by the load. One of the reasons for some users blaming at apache+mod_wsgi is because they maintain the default (bloated) apache configuration like php users/sysadmin tend to do.

gardentheory 15y ago

Well i think the gist is that serving files and running applications have different resource requirements. Therefore it is common to have a proxy serve statics and proxy in addition to an application server running python. The advantage with uwsgi as i understand it is that the proxy protocol is faster than http.

unbit 15y ago
No, uWSGI has nothing to do with performance. Its strength is in the features and operational modes. Each application is diferent from the others and (could) requires specific tuning. This is the spirit of the project, that is at the opposite of solutions like gunicorn. There is no "best choice", it depends on how you approach to system administration/development. Saying uWSGI is better than gunicorn (or the opposite) is like comparing bananas with oranges.
- gardentheory 15y ago
  I have only used apache as an application server with mod wsgi behind nginx. I have not used gunicorn or uwsgi. Yhanks for the correction, I should have just stopped my explanation before that.

unbit 15y ago

in both gunicorn and php you have to choose the number of workers/processes. Most of the time (unless you use php-fastcgi) the number of php processes is choosen by the sysadmin as it maps 1:1 with apache processes. The same is true for mod_wsgi. There is always some form of configuration independently by the load. One of the reasons for some users blaming at apache+mod_wsgi is because they maintain the default (bloated) apache configuration like php users/sysadmin tend to do.