>
> A quick comment about a couple of tests I did regarding RedisSession (that 
> also has a "with_lock" argument).
> To the test, I updated web2py locally to version 
> 2.16.1-stable+timestamp.2017.11.14.05.54.25
> And then I run my apps using:
>
>    - RedisSession(..., with_lock=False)
>    This is the way that I was already using it, and apps run normally 
>    (pretty fast because they do simple tasks)
>    
>    - RedisSession(..., with_lock=True)
>    Using this, the apps start responding with hughe delay; the same 
>    requests that usually took less than a second to complete, start tooking 
>    between 6 and 10 seconds.
>
> That seems odd. This should have minimal effect on the time to complete a 
single request if there are no other simultaneous requests involving the 
same session. How are you testing?

It does look like the Redis session code puts a 2 second lock on the 
session when it is first read at the beginning of a request, so if a page 
makes multiple simultaneous Ajax requests when it loads, each request will 
take up to 2 seconds before the next can be processed (if I'm reading the 
code right, an update to the session will result in the lock being 
released, but if no update is made, it looks like you have to wait for the 
full 2 seconds to expire).

Note, locking with Redis cache works differently -- the lock is held only 
during the time it takes to read from or write to the cache, not for the 
duration of the entire request or beyond.

Anthony

-- 
Resources:
- http://web2py.com
- http://web2py.com/book (Documentation)
- http://github.com/web2py/web2py (Source code)
- https://code.google.com/p/web2py/issues/list (Report Issues)
--- 
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to web2py+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to