To the original post in this thread, I think the idea for distributing session files across the file system is sensible. I use what I believe is a similar web2py capability for distributing files and I know it works and is scalable.
As for the rest of the thread, scalability is a moving target. Bottom line -- somebody has to be smart or lucky enough to build a killer web2py app and then the web2py community has to support efforts to make sure it scales. I'm encouraged to see this discussion. On Dec 1, 11:57 am, mdipierro <mdipie...@cs.depaul.edu> wrote: > We should have a mechanism for storing sessions clientside but this is > a speed issue not a scalability issues. Storing sessions in encrypted > cookies makes a each request 1-2ms faster by trading bandhwidth > (required to communicate the session in cookie) with file IO (required > to locate and access the session in a file). > > Scalability-wise sessions in files do not present a problem as long as > one uses a load balancer with support with sticky sessions. > > On common problem arises when there are too many session files in the > same folder (the os becomes slow accessing the folder). This problem > has been solved in trunk last week by creating a sub-folder tree > structure for the session folder. > > Session in files some advantages of sessions in cookies: they can > contain more data. They can be controller server-side (checked, > deleted, modified). They can be locked to force per-user serialization > of form processing(default in web2py). > > Bottom line: current sessions are not a scalability issue but it would > be nice to have the option of sessions in signed cookies. It is not > difficult to do and we have it by the end of the year. > > This will be a major speed up for system that do not have a filesystem > and currently require storing sessions on datastore, like on GAE. > > Massimo > > On Dec 1, 10:31 am, VP <vtp2...@gmail.com> wrote: > > > This is an example -- I think -- where web2py still needs to be proven > > in terms of scalability. > > > Yes, sessions can be stored in database, turned off in specific > > functions, and regularly deleted. But I still think that there > > should be a better systematic way of handling sessions in heavy > > applications. I think the current set up is not effective when you > > have large volume of users, which suddenly builds up many sessions. > > > Small things like this don't matter much until things get large > > scaled. > > > === > > > To take web2py to the next level, I think Massimo might need to lay > > out milestones or visions to be achieved in future releases of > > web2py. > > > On Nov 30, 6:07 pm, Stef Mientki <stef.mien...@gmail.com> wrote: > > > > On 30-11-2010 21:08, VP wrote:> I think .NET and web2py are not > > > competitors. They are different ball > > > > games. When things scale large, everything is important. A small > > > > design issue might be magnified. I don't think web2py is proven yet, > > > > in terms of scalability. What web2py needs is at least one real > > > > example to show that it is scalable and what are the limits at the > > > > extreme. > > > > I'm not sure were session files are used for, > > > but isn't file access much slower than database access ? > > > > Can session files be turned of ? > > > > cheers, > > > Stef > >