I saw a relatively/mostly related issue on the repo and so I feel I should
give an answer...
web2py is a web framework: we're not in the business of managing processes
nor webservers. We're in the business of realizing an app that does what
you want in response to a web request.
For development purposes (and relatively small deployments) web2py includes
a single process threaded webserver, that is rocket.
NOBODY says that you MUST run web2py under rocket. For all matter and
purposes, in production we (or, for better saying, people who manage
production-grade environments) highly encourage uwsgi + nginx on unix and
fastcgi+iis on windows.
web2py is compatible with the wsgi standards which ATM is the only largely
accepted way to run python web-serving apps. Usually frontends are I/O
bound and not CPU bound: threading is the best choice there, so the rocket
threaded webserver is just a matter of providing a "sane default".
web2py's scheduler is just something you can offload CPU (or long-running)
tasks to an external process. Webservers DO enforce a timeout on each and
every request (again, it's a matter of "sane defaults" on their end) and
so the "pattern" of having a facility that offloads those kind of things to
"something else" has gained traction.
web2py (and the scheduler) just adhere to "standards" and "sane defaults".
I wouldn't be startled by the statement "should my web-serving process
consume 1/10th of the CPU resources given to external processes" because
the role of the web-serving process is reacting to user inputs. If the
reaction is a web-page, usually the time taken to generate the page is far
less than the time it takes to transfer it (or, for better saying, the time
web2py spends in rendering the page is far less than the time taken to
retrieve results from the db and shipping that result to the user's
browser). If the reaction of a user input is to calculate the prime numbers
from 10^56 to 10^101 ... well, you need to ship that work elsewhere because
running it inside a web-serving app would only mean forcing the user
waiting for a reply wayyyyy too much.
Back to the "how should web2py be handled"..... you can choose whatever you
like, according to your own app's needs and number of users (or, again for
better saying, number of requests to serve per second): USUALLY you'd want
something like uwsgi+nginx or iis+fastcgi to do the heavy work of spawning
web2py processes as needed and having those serve the needs of the users
requesting pages. They do an excellent job and provide nice facilities
(like buffering) to make everything as speedier as possible.
Long running tasks can OPTIONALLY be handled by an external process (like
the scheduler) to avoid hitting the "sane limits" defaults imposed by the
majority of webservers (like that a request should be handled in AT MOST 60
seconds, which, if you reeeally think it through, is a REEEEALLY long time
to wait for whatever webpage the user asks for).
- http://web2py.com/book (Documentation)
- http://github.com/web2py/web2py (Source code)
- https://code.google.com/p/web2py/issues/list (Report Issues)
You received this message because you are subscribed to the Google Groups
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.