scaling web2py

[Pierre]

Hi,

I am very familiar with the concepts of threads, processes and scaling issues. What i understand so far is:
(1) a web2py application process manages a number of threads dealing with requests
(2) I can run one or more additional scheduler processes to unload the main process (#1)

doing (2) I may end up with more computing power allocated to  schedulers than to the w2p application ?

(3) I read that an Oracle server can run in multi-process mode but every process is independant ?
what for to run the same app in multi-process mode if processes can't coordinate themselves ?
is this only good in the case of independant applications running on the same server ?

Can a web2py app run in multi-process mode and stay synchronized ? if not how to scale it besides adding more threads to the main process?

[Dave S]

The normal scaling (AIUI) is done with nginx or apache, and having worker threads dispatched to run each request separately.  Web2py is designed to work in that environment.  Each request accessing the database will take a connection from the connection pool.  Scheduled tasks run in other threads (that get launched at startup (manually or startup scripts).  Requests don't usually monitor scheduled tasks, but a page can use refresh interval or jquery to watch for when a task has finished.

What synchronization issues do imagine will occur?

What workflow are you trying to handle?

/dps

[Niphlod]

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).

 

[Massimo Di Pierro]

First of all I refer you to niphlod which is very comprehensive. Let me add something in relation to your last questions.

When you run web2py with rocket, rocket uses threads. When you run web2py with nginx+uwsgi, uwsgi runs in emperor mode and it uses multiple processes (not threads) and you can specify the number of workers.

Another solution for multiple web2py porcesses is nginx + gunicorn (http://www.web2pyslices.com/slice/show/1561/nginx-gunicorn).

There is an almost unlimited number of combinations of WSGI server and load balancers that support threads, processes, async. We recommend nginx+uwsgi. it works and scales well with no known memory issues.