> > 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.
