El sábado, 21 de abril de 2018, 18:00:36 (UTC-3), Anthony escribió:
>
> 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 is weird indeed.
I'm testing in my local environment, with web2py updated to the version I
mentioned, I use uwsgi and nginx, but I tried also with web2py's embedded
server.
I'm testing on an admin app that I developed, it doesn't make ajax calls,
it is just a bunch of urls where I put a grid with pagination and some
forms to edit rows, stuff like that.
I've noticed that when I use RedisSession(..., with_lock=True) the app
takes much longer to respond.
I've measured the change using the Chrome Inspector, within the Network
tab, checking for the TTFB (time to first byte).
Normally, running locally, the TTFB of any request URL is around 50ms.
But when I set RedisSession(..., with_lock=True), flushall redis and
restart uwsgi, the TTFB raises to 6s up to 10s.
This happens even with requests where I run session.forget(response)
Something particularily weird is that once every 5 or 6 times, the request
responds fast (with a low TTFB).
I mean, the same request URL, I stay with the Chrome inspector opened in
that tab, and reload the page several times.
The TTFB is always between 6s and 10s, but every 5 or 6 times, it is low
(about 50ms as it should be).
I'm running Redis 3.2.10
Here is my db.py, but I don't think it has anything out of the ordinary:
db = DAL(
'postgres://%s:%s@%s/%s' % (CONFIG.db_user, CONFIG.db_user_password,
CONFIG.db_host, CONFIG.db_name),
migrate=False,
lazy_tables=True,
folder=os.path.join(CONFIG.path_datos, 'databases'))
_conn = RConn('localhost', 6379)
sessiondb = RedisSession(
redis_conn=_conn,
session_expiry=172800, # two days
with_lock=True)
session.connect(request, response, db=sessiondb)
auth = Auth(globals(),
db,
hmac_key=Auth.get_or_create_key(filename=os.path.join(CONFIG.path_datos,
'auth.key')))
auth.define_tables()
# ... define all the tables
# ... configure auth settings
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.
>
I see what you mean, I took a look at the code.
I've read this from the book: "*The redis backend for sessions is the only
one that can prevent concurrent modifications to the same session: this is
especially true for ajax-intensive applications that write to sessions
often in a semi-concurrent way. To favour speed this is by default not
enforced, however if you want to turn on the locking behaviour, just turn
it on with with_lock=True parameter passed to the RedisSession object*"
Considering that, and giving that until now I stored the sessions in the
db, I guess that it won't hurt to use RedisSession(..., with_lock=False),
as it would remain being the same that before (regarding the lock), right?
Anyway, let me know if there is some additional test that I can do to
figure out why the app takes longer using RedisSession(..., with_lock=True).
Regards,
Lisandro
--
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.
