On Thursday, January 14, 2016 at 11:12:12 AM UTC-5, Richard wrote: > > This is true for any other cache except cache.ram right? >
Right. cache.ram works because it doesn't have to pickle a Python object and put it into external storage (and therefore create a fresh copy of the stored object via unpickling at retrieval time). Rather, it simply stores a pointer to the existing Python object within the current Python process. Of course, this limits cache.ram to a single process, so if your app is being served by multiple processes, each will have its own version of cache.ram. > If so, there is no gain with cache.redis the way I use it... > Well, the gain with Redis is that it will actually work, though you will have to adjust your code to save the whole dictionary back to the cache upon update. > @Anthony, are you sure about the issue with uwsgi/nginx and cache.ram dict > update? > I think so. You might try configuring uwsgi to run a single process with multiple threads instead of using multiple processes. Not sure how that will impact performance. > I guess, I should start to look at how to get rid of these global dict > while not degrading system performance. There surely place where I use > these global vars that wouldn't suffer from a little query to the backend, > but for grid where the performance was the greatest or simplifying code was > acheive with those it will be difficult to stop using them... > Is it really a problem to write the whole dictionary to Redis? How often are updates happening? 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.
