I promise you that 2.1.0 (in one or two weeks) will adress the first issue as I have from Anthony that allow you to specify which models to run.
About the second issue. Sessions are only locked per user not globally in order to prevent inconsistent session states. You can session._unlock(response) them if you like. Anyway, it is possible that in 2.1 we will also have clientside sessions (in cookies). That is what Flask does. They may provide faster session handling if sessions are very small and there are multiple servers behind a load balancer. On Saturday, 1 September 2012 22:54:58 UTC-5, VP wrote: > > Web2py can be used to build fairly effortlessly either complex > applications with *small* numbers of concurrent users (*small* here is > relatively and objective) or simple applications with *large* numbers of > concurrent users. But if you want to build complex applications with > large numbers of concurrent users (again "large" is relatively), there are > a few things that might hurt you. > > First, models and controllers are executed at every request. You can > divide big controllers into many small ones; but when your app is complex > enough, it's going to be difficult. With large numbers of concurrent > users and complex controllers and models, delays might be noticeable. > > Second, session handling. Sessions are locked at the beginning of a > request and is released only when the request is finished. You can > "session forget"; but when your app is complex, this is not feasibly or > natural. When your controllers are little compute intensive, delays will > be noticeable. Further, if you have a sudden peak, session files will > quickly accumulate and slow things down. I think web2py does not yet have > an effective and efficient way to delete session files. > > But if you want to build complex apps with many concurrent users, I think > you need a very flexible micro-framework with minimal assumptions. But you > will need to do a lot more. And you had better know very well what you are > doing when you put all of these components together. Otherwise, you might > end up with an unsecured, slow or clumsy system, when you can be much > better off using web2py, knowing its limitations. In other words, something > has got to give. > > > > > > > > > > On Saturday, September 1, 2012 11:48:01 AM UTC-5, Webtechie wrote: >> >> >> I would like to use web2py for a web application which has large >> databases (really large) , expects high volume of traffic . Are there any >> ways to make web2py apps run faster ? (like really faster ) , (looking for >> solutions apart from pooling more hardware and replacing Cpython wth pypy , >> running on a non-blocking server like tornado ) . How can i optimise web2py >> for my needs ? are web2py applications scalable ? >> > --
