So, we came to the conclusion that combining the use of G-event as the server, and redis for caching, injects instabilities, with random hangings and crashing requests: I ruled-out the factor of using 0.13.x versions of G-event vs. the 1.x release - it happens in both cases. I ruled-out using redis for session-store or just for caching - it happens in any combination. When I use any form of redis-integration, while using any other server (i.e, rocket), everything works smoothly. When I use G-event of any version, while not using redis for anything, everything works smoothly. But when combining the two, and using G-event of any version while using redis for anything (session-store and/or caching), things go haywire...
Our application is mainly cpu-bound, and we use a physical-machine (with no virtualization) with multiple-cores, so we want to take advantage of all the cores. And since python can-not do multiple things at once (due to the GIL), we need to run multiple python-processes. And since we rely heavily on caching, with keys that gets updated periodically by the use of the app, we really must have centralized-caching in some form. So for now, we are temporarily using python's simple-http server (we are running it via circus+chaussette, btw...), which makes things... well... noticeably less-snappy... My suspected culprit is the use of thread-locking in the web2py's redis-integration code. Am I correct? How can this be remedied? Can I safely remove the thread-locking code entirely from web2py's redis-modules (for single-thread servers like G-event)? -- 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.
