If web2py actually encrypt sessions, that will take quite some time, and saving/retrieving sessions can be computing intensive. I think session data signed and not encrypted is the way to go.
With respect to scalability, the "computation" here is the saving to the filesystem. This is the burden to move from the server to the client with cookie-based session. As I said, imagine you have 100 users active, the difference will be accessing the local filesystem for 100 of them, versus none (when you move this burden to the client). On Tuesday, October 16, 2012 2:27:01 PM UTC-5, Niphlod wrote: > > > On Tuesday, October 16, 2012 7:46:16 PM UTC+2, VP wrote: >> >> >> I think one advantage of moving session data to the client side is >> scalability. There ought to be a noticeable difference between 100 >> processes writing to the same filesytem and these computations moved to the >> client side. >> >> > yep, you "save" the filesystem for accesses, but the time taken > serializing/deserializing remains the same, plus there's > encryption/decryption and the time took to send extra bytes back and forth > server and client. There's no "computation" moved to the client side. > Anyway, it's another option you can use with web2py, and as always, to be > chosen with a grain of salt. > > --
