Hi, I need to cache various things at server startup (parsed CSS selectors, parsed Liquid template objects, Liquid drop object registry etc..) and I''d like a single cache location, instead of a cache on each web node. A dedicated memcached node looks like a good idea but I''m worried that the cost of marshaling my objects on each cache get will out-weight the speed advantages gained by using the cache in the first place. Does anyone have any tips on what to do in this situation? Cheers Ian. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
On Sep 18, 2006, at 8:11 AM, Ian Leitch wrote:> A dedicated memcached node looks like a good idea but I''m worried > that the cost of marshaling my objects on each cache get will out- > weight the speed advantages gained by using the cache in the first > place. > > Does anyone have any tips on what to do in this situation?Yes. Test your assumptions about speed. Memcached is easy enough to setup and experiment with. Also: remember that memcached is not persistent and if you want to cache things at startup which hang around indefinitely, you''re using it wrong. What''s so bad about keeping a local copy of the cache if it''s never going to change and consistent across all nodes? -- Chris Wanstrath http://errtheblog.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
Ah, I didn''t know memcached wasn''t persistent. Having a cache per node isn''t a big problem, it''s just that i''ll need a mechanism in place to ensure the caches don''t get out of sync. Once I start clustering Mongrel, I''m going to need something that I can use to share objects among each ruby process. On 18/09/06, Chris Wanstrath <chris-G5sj8e7vJc8@public.gmane.org> wrote:> > > On Sep 18, 2006, at 8:11 AM, Ian Leitch wrote: > > > A dedicated memcached node looks like a good idea but I''m worried > > that the cost of marshaling my objects on each cache get will out- > > weight the speed advantages gained by using the cache in the first > > place. > > > > Does anyone have any tips on what to do in this situation? > > Yes. > > Test your assumptions about speed. Memcached is easy enough to setup > and experiment with. > > Also: remember that memcached is not persistent and if you want to > cache things at startup which hang around indefinitely, you''re using > it wrong. What''s so bad about keeping a local copy of the cache if > it''s never going to change and consistent across all nodes? > > -- > Chris Wanstrath > http://errtheblog.com > > > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---
OK, Drb is what I was looking for. A few wrapper script here and there and I can use my objects as if they were local. For anyone doing this, remember to include DRbUndumped into any classes your server will return instances of, you''ll be unable to transparently access the remote methods otherwise. On 18/09/06, Ian Leitch <port001-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > Ah, I didn''t know memcached wasn''t persistent. Having a cache per node > isn''t a big problem, it''s just that i''ll need a mechanism in place to ensure > the caches don''t get out of sync. Once I start clustering Mongrel, I''m going > to need something that I can use to share objects among each ruby process. > > > On 18/09/06, Chris Wanstrath <chris-G5sj8e7vJc8@public.gmane.org> wrote: > > > > > > On Sep 18, 2006, at 8:11 AM, Ian Leitch wrote: > > > > > A dedicated memcached node looks like a good idea but I''m worried > > > that the cost of marshaling my objects on each cache get will out- > > > weight the speed advantages gained by using the cache in the first > > > place. > > > > > > Does anyone have any tips on what to do in this situation? > > > > Yes. > > > > Test your assumptions about speed. Memcached is easy enough to setup > > and experiment with. > > > > Also: remember that memcached is not persistent and if you want to > > cache things at startup which hang around indefinitely, you''re using > > it wrong. What''s so bad about keeping a local copy of the cache if > > it''s never going to change and consistent across all nodes? > > > > -- > > Chris Wanstrath > > http://errtheblog.com > > > > > > > > > > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk -~----------~----~----~----~------~----~------~--~---