So... in trunk we have an experimental solution to the session issue
proposed by Anthony. We allow disabling of session logic using routes.py.
routes_in = [('/welcome','/welcome',dict(web2py_disable_session=False)]
This solution many or many not stay in this form. We are testing it and
discussing it. Anyway, we find that the speed-up of disabling sessions on
my laptop is 0.15ms/request.
In comparison some recent optimizations in regex compiling (also in trunk
now to be release in web2py 2.1.0) was more like 0.35ms/request.
On Sunday, 2 September 2012 09:49:08 UTC-5, Anthony wrote:
>
> I think it'd be nice to have session created explicitly inside a "WITH"
>> statement block so that users create sessions only when they want. But I
>> don't know if it's feasible because I suspect sessions are created
>> automatically and passed into the exec environment, and it appears sessions
>> are used to keep track of a few things in web2py.
>>
>> In other words, the web2py's way is sessions are created by default and
>> optionally "forget". But it *might* be better if sessions are not created
>> by default and users are given an easy method to create sessions.
>>
>
> Right, there is a small performance hit given that web2py automatically
> loads the session at the start of every request. You also suggested,
> though, that the application logic for turning off sessions when not needed
> would somehow be more complex and difficult than it would be if instead you
> had to turn on sessions when you need them, and it's not clear to me that
> that is the case. In web2py, to simulate the latter, I think you can just
> do session.forget(response) at the beginning of every request (early in
> first model file), and then do session.connect(request, response) at some
> later point in the code when you do need to read/write the session. So,
> your application logic shouldn't really need to be any more complex in
> web2py.
>
> Also, note, web2py does not write to the session file on requests in which
> the session does not change, so there is no reason to forget/unlock the
> session merely to avoid unnecessary file writing. The only reason to unlock
> the session file is to prevent one request from a given user from blocking
> other concurrent requests from that same user -- and this would generally
> only be an issue if the user is loading a page with multiple simultaneous
> Ajax requests that don't use the session. Note, if the multiple Ajax
> requests actually do need the session, then you do in fact want them to
> block each other because otherwise you could introduce race conditions with
> the session.
>
> Anthony
>
--
