The fact is that there is not one number to measure scalability.
There are many parameters like:
number of requests/second (average)
number of requests/second (peak)
complexity of those requests/second (static pages, dynamic pages,
types of db queries, do they use caching).
number of servers used.
type of database used.
Is the database replicated? (how many clients? how many servers?).
I stand by my comment that it does not matter which framework you use.
It matters how the database is accessed and designed. If the db
scales, but the app is slow, you can replicate web2py (and the web
server) as much as you want.
I know there are users here who have web2py behind a load balancer (if
you do please let us know so the information is public).
There are frameworks (microframeworks) that are more lightweight than
web2py because they do less. That means on a single machine (without
replicating the db not the web serve) for simple apps that do not need
the extra web2py stuff, they will be faster and therefore hey will be
able to serve more pages/second before they start to fail. I am not
sure this is the case for apps that need session, authentication, etc.
web2py introduces a penalty when you have lots of tables and there are
some optimizations that need to be done in that case.
There are some tricks to speed-up web2py which are important to scale
it:
- Even if your app does not run on GAE, create an empty APP on GAE and
use it to server ALL the static files. Use your server only for
dynamic HTML pages.
- set migrate=False
- do not use {{import ...}} too much, use {{block}} if necessary.
- remove un-necessary {{...}} from the layout
- move as much code from models to modules and/or controllers
- make many small controllers as opposed to one large one
- bytecode compile the app
- cache as many selects as possible in ram.
- use sticky session in the load balancer
- use Field(...,'upload',uploadseparate=True)
- use session.connect(request,response,separate=True)
- try separate a complex app into smaller modular apps that share a
central authentication service.
- run a background process that clears expires sessions
- run a background process for time consuming tasks such as sending
emails
Massimo
On Dec 1, 6:54 pm, John Heenan <johnmhee...@gmail.com> wrote:
> The OP asked "What's the 'largest' scale web2py is known to perform
> well on? "
>
> Massimo evaded the question and no one else has provided an answer.
>
> The core of Erlang is very simple. Erland does no
>
> On Dec 2, 5:09 am, Branko Vukelic <bg.bra...@gmail.com> wrote:
>
> > Erlang is for humongous, real-time, distributed, and highly-available apps.
>
> > Here's an example (maybe quoted one time too often):
>
> >http://www.sics.se/~joe/apachevsyaws.html
>
> > On Wed, Dec 1, 2010 at 6:45 PM, John Heenan <johnmhee...@gmail.com> wrote:
> > > The elephant in the room has not gone away Massimo.
>
> > > Web2py is great for small projects.
>
> > > DotNet is great for small and large projects.
>
> > > The elephant in the room is not only the untested scalibility of
> > > web2py but also the amount of resources that neeeds to be thrown at
> > > web2py compared to DotNet and other frameworks as scale increases.
>
> > > One of the glaring defciences in web frameworks that use Python is the
> > > glaring engineering weakness of using thread per request web serving
> > > instead of using event per request web serving. I think I have pointed
> > > this out a number of times on this fourm, but it just does not sink
> > > in. I even pointed out how Linux loast a PR war over this issue.
>
> > > There is no need for Python based web frameworks to use thread per
> > > request web serving.
>
> > > John Heenan
>
> > > On Nov 30, 4:05 am, mdipierro <mdipie...@cs.depaul.edu> wrote:
> > >> You achieve scalability by replicating the web server behind a load
> > >> balancer. This is documented in the book, chapter 11, using HAProxy.
> > >> All frameworks work the same way in this respect. web2py has no
> > >> intrinsic limitations. The bottle neck is the database connection. All
> > >> frameworks have the same problem. You can replicate the database too
> > >> and web2py supports multiple database clients with Round-Robin.
>
> > >> On a small VPS, web2py in average, should execute one page in 20ms.
> > >> Depending on how many requests/second you need you can determine how
> > >> many servers you need.
>
> > >> web2py apps run on Google App Engine and that means arbitrary
> > >> scalability as long as you can live with the constraints imposed by
> > >> the Google datastore (these limitations will go away as soon as Google
> > >> releases MySQL in the cloud, which they announced some time ago).
>
> > >> Please ask the consultant: which .NET feature makes it scale any
> > >> better than web2py or Rails? If he explains we can address it more
> > >> specifically.
>
> > >> Massimo
>
> > >> On Nov 29, 11:56 am, Lorin Rivers <lriv...@mosasaur.com> wrote:
>
> > >> > The project I'm working on has hired a consultant who is now
> > >> > recommending .Net in place of web2py or even rails.
>
> > >> > What's the 'largest' scale web2py is known to perform well on?
>
> > >> > --
> > >> > Lorin Rivers
> > >> > Mosasaur: Killer Technical Marketing <http://www.mosasaur.com>
> > >> > <mailto:lriv...@mosasaur.com>
> > >> > 512/203.3198 (m)
>
> > --
> > Branko Vukelić
>
> > bg.bra...@gmail.com
> > stu...@brankovukelic.com
>
> > Check out my blog:http://www.brankovukelic.com/
> > Check out my portfolio:http://www.flickr.com/photos/foxbunny/
> > Registered Linux user #438078 (http://counter.li.org/)
> > I hang out on identi.ca:http://identi.ca/foxbunny
>
> > Gimp Brushmakers Guildhttp://bit.ly/gbg-group
>
>
