When making consecutive ajax calls, we've noticed very lengthy TTFB (time-to-first-byte) values in the Chrome devtools for any request that goes through a web2py controller. When called individually, they do not appear to take nearly as long, but when fired off simultaneously as XHR, they seem to take much longer.
For instance, one particular method might take 216ms to return if requested normally, but as part of a batch of requests, it takes 800-900ms. Even if it's the first request. <http://i.imgur.com/HIxyvNe.png> <http://i.imgur.com/rtladAX.png> Examining the output of web2py's built-in profiling feature, the results tend to be something along these lines: <http://i.imgur.com/0bsu4ZA.png> with thread.lock.acquire() (as part of the db.py processing, going by the tree in the profiler) taking roughly half of the response time. Now, we have tried both MySQL sessions and cookie sessions. The above images are taken while using MySQL sessions. So I don't think this has anything to do with locking from file-based sessions. Is this normal behavior? Are there any steps we can take to alleviate this issue? -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
