Excerpts from Dolph Mathews's message of 2013-10-28 08:40:19 -0700: > It's not specific to mysql (or sql at all), but keystone is using > dogpile.cache around driver calls to a similar effect. > > http://dogpilecache.readthedocs.org/en/latest/ > > It can persist to memcache, redis, etc. >
I once heard a quote.. "I had a performance problem, so I added caching. now I have two performance problems." Caching is unbelievably awesome in the jobs it can do well. When the problem is straight forward and the requirements are few, it is just the right thing to relieve engineering pressure to make an application more scalable. However, IMO, more than narrow, well defined cache usage is a sign that the application needs some reworking to scale. I like the principle of "let's use dogpile so we don't have to reinvent multi-level caching". However, let's make sure we look at each performance issue individually, rather than just throwing them all in a cache box and waving the memcache wand. > > https://github.com/openstack/keystone/blob/master/keystone/common/cache/core.py > > On Fri, Oct 25, 2013 at 6:53 PM, Qing He <[email protected]> wrote: > > > All,**** > > > > Has anyone looked at the options of putting a distributed caching system > > in front of mysql server to improve performance? This should be similar to > > Oracle Coherence, or VMware VFabric SQLFire.**** > > > > ** ** > > > > Thanks,**** > > > > ** ** > > > > Qing**** > > > > _______________________________________________ > > OpenStack-dev mailing list > > [email protected] > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
