On Monday, 24 September 2012 at 5:21 AM, Brian Durand wrote: > In the example you give, the cache would not expand from 1GB to 5GB unless > you're storing very small values with very small keys. If you average key + > value size is around 1K, then the cache would only expand by ~4%, not 500%. > If you need to store lots of small values, you should probably go directly to > storing raw values directly with dalli since any use ActiveSupport::Cache > will add the overhead of an extra layer. If you're storing non-Strings to > memcache, the overhead of the internal instance variable names are probably > adding a far larger overhead than Entry is adding since the names are stored > in strings in the serialized object. > > I think it makes the most sense to look at ActiveSupport::Cache as a generic, > consistent interface to a variety of caching back ends and have the default > implementations support all features. There's nothing to prevent someone from > implementing an optimized memcache backend if they have special needs for > performance. > This is the root of the disagreement I guess. ActiveSupport::Cache is a generic interface to a variety of backends, each of which have their own limitations and restrictions. Just as active record does its best to provide a consistent interface but at the edges there are limitations or differences in how the different databases behave or query languages they support. If someone were to propose changing the way active record stores its data in postgresql in order to implement support for ON DUPLICATE KEY UPDATE, we'd reject that out of hand.
Running the same code against two different cache stores isn't particularly valuable in the face of the different performance characteristics of the different backends. No one is switching between memcached, redis and memory store on a regular basis. As for the particular nil vs missing thing, the memcached gem differentiates between the two cases, but as it depends on native code it's not something that we want to have as a dependency. Perhaps the simplest solution for this is for you to approach mike perham who looks after dalli and try to fix this particular issue there? There are also various forks of libmemcached_store from 37signals in use which will most likely do what you want. > On Saturday, September 22, 2012 1:55:54 PM UTC-7, Michael Koziarski wrote: > > On Sunday, 23 September 2012 at 12:32 AM, Xavier Noria wrote: > > > On Fri, Sep 21, 2012 at 8:48 PM, Brian Durand > > > <[email protected] (javascript:)> wrote: > > > > > > Hi Brian, > > > > > > > The Entry model does provide one other feature which I think also > > > > warrants keeping it around and which is even potentially more valuable > > > > than the race_condition_ttl. It allows the cache to store nil values. > > > > > > You are right. That in itself justifies Entry I believe. We could add a > > > comment in the source code of the memcached store that documents these > > > two pros for the next guy wondering about why we use Entry :). > > I disagree very strongly with this line of reasoning. If you're using > > memcached as a cache store, you should be relying on its semantics, which > > is that nil and 'no value' are identical. > > > > Even with the optimised version you're talking storing 58 bytes vs 12 > > bytes, for a site with a 1GB of stuff to store, should they really need to > > allocate 5G of cache storage just so people who want to store nil (without > > using their own wrapper) can? > > > > The particular site where I encountered this issue upgraded to a version of > > rails which used AS::Entry and had their working set expand from 4G to more > > than 10. Frankly that's not even close to an acceptable trade off. > > -- > You received this message because you are subscribed to the Google Groups > "Ruby on Rails: Core" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/rubyonrails-core/-/OOiW4Vsq61oJ. > To post to this group, send email to [email protected] > (mailto:[email protected]). > To unsubscribe from this group, send email to > [email protected] > (mailto:[email protected]). > For more options, visit this group at > http://groups.google.com/group/rubyonrails-core?hl=en. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
