First let me say that Rails caching is very very cool. The traffic (and responsiveness) I''ve saved by added 10 lines of ruby code would be enourmous, if I actually had traffic... ;) Sweepers as observers are great, btw. Since every page of my side is dynamic, once I did some DB optimization I''m caching the content of the index page which was taking the bulk of the time to load & render. I''ve got a sweeper setup which expires both the feed page and the index fragment on create & update. It seems to work great. But I have a question on how sweepers work with fragment caches. If I''m using fast cgi and memory cache, when I expire a fragment on one process will it get expired across the others? (I''m assuming that a page cache being disk pages will.) If not, what are the advantages/pitfalls of a moving to a different cache? And, finally, how hard is it to keep a DRb server running without having to worry about it? Thanks, -w -- Will Schenk http://www.sublimeguile.com
> But I have a question on how sweepers work with fragment caches. If > I''m using fast cgi and memory cache, when I expire a fragment on one > process will it get expired across the others? (I''m assuming that a > page cache being disk pages will.) If not, what are the > advantages/pitfalls of a moving to a different cache? And, finally, > how hard is it to keep a DRb server running without having to worry > about it?You definitely don''t want to use the memory cache on FastCGI. The memory cache is pretty much only useful with WEBrick. So either get a DRb server going (and make sure its in a startup script or something, so it''ll survive a machine restart) or use the file cache. I''m doing the latter for Ta-da. -- David Heinemeier Hansson, http://www.basecamphq.com/ -- Web-based Project Management http://www.rubyonrails.org/ -- Web-application framework for Ruby http://www.loudthinking.com/ -- Broadcasting Brain
On 10.3.2005, at 16:34, David Heinemeier Hansson wrote:> > You definitely don''t want to use the memory cache on FastCGI. The > memory cache is pretty much only useful with WEBrick. So either get a > DRb server going (and make sure its in a startup script or something, > so it''ll survive a machine restart) or use the file cache. I''m doing > the latter for Ta-da.What is the supply of DRb or Memcached servers on shared hosting plans in general and TextDrive in particular? Is it better (or the only way) to just rely on file cache with them? //jarkko -- Jarkko Laine http://jlaine.net http://odesign.fi _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
Filestore it is -- worked out some permission issues and it''s great. How can I see if a fragment is already in cache? I''d like to avoid the db and related processing in the action if possible, and I''m trying to use read_fragment to test to see the existence. How do I figure out the name of that the request will be cached under? (i.e. it looks like severname/controller[/action] for when action !index.) I''ve written some of this up at http://www.sublimeguile.com/entry/show/Rails-Caching Thanks, w On Thu, 10 Mar 2005 16:37:33 +0200, Jarkko Laine <jarkko-k1O+Gnc6WpmsTnJN9+BGXg@public.gmane.org> wrote:> > On 10.3.2005, at 16:34, David Heinemeier Hansson wrote: > > > > You definitely don''t want to use the memory cache on FastCGI. The > > memory cache is pretty much only useful with WEBrick. So either get a > > DRb server going (and make sure its in a startup script or something, > > so it''ll survive a machine restart) or use the file cache. I''m doing > > the latter for Ta-da. > > What is the supply of DRb or Memcached servers on shared hosting plans > in general and TextDrive in particular? Is it better (or the only way) > to just rely on file cache with them? > > //jarkko > > -- > Jarkko Laine > http://jlaine.net > http://odesign.fi > > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails > > > >
Will, On 10.3.2005, at 16:57, Will Schenk wrote:> Filestore it is -- worked out some permission issues and it''s great. > > How can I see if a fragment is already in cache?Rails writes to the log if a cache fragment has been hit. I don''t remember the exact wording but it''s there right next to the sql statements. //jarkko -- Jarkko Laine http://jlaine.net http://odesign.fi _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
Maybe I didn''t ask my question correctly: from a controller, how can I generate the fragment cache key without hardcoding the server name? The request has the properties "host", "domain", and "subdomain" and I can construct from there. It looks like the cache_erb_fragment uses "url_for" to contruct the key from the name, stripping out the http:// bit. (Sorry for all the misdirected emails Jarkko!) -w On Thu, 10 Mar 2005 17:03:23 +0200, Jarkko Laine <jarkko-k1O+Gnc6WpmsTnJN9+BGXg@public.gmane.org> wrote:> Will, > > On 10.3.2005, at 16:57, Will Schenk wrote: > > > Filestore it is -- worked out some permission issues and it''s great. > > > > How can I see if a fragment is already in cache? > > Rails writes to the log if a cache fragment has been hit. I don''t > remember the exact wording but it''s there right next to the sql > statements. > > //jarkko > > -- > Jarkko Laine > http://jlaine.net > http://odesign.fi > > >-- Will Schenk http://www.sublimeguile.com http://www.myelinate.com
On Thu, 10 Mar 2005, Will Schenk wrote:> First let me say that Rails caching is very very cool. The traffic (and > responsiveness) I''ve saved by added 10 lines of ruby code would be > enourmous, if I actually had traffic... ;) > > Sweepers as observers are great, btw. Since every page of my side is > dynamic, once I did some DB optimization I''m caching the content of the > index page which was taking the bulk of the time to load & render. I''ve got > a sweeper setup which expires both the feed page and the index fragment on > create & update. It seems to work great. > > But I have a question on how sweepers work with fragment caches. If I''m > using fast cgi and memory cache, when I expire a fragment on one process > will it get expired across the others?no. UNLESS you configure your setup to have only one fastcgi process. in general caching in memory under fastcgi is a terrible idea unless you compile and install the session affinity patch - and even then you''d better understand what you are doing. the biggest reason for not doing so is that session data evaporates if your process crashes.> And, finally, how hard is it to keep a DRb server running without having to > worry about it?i have about 100 running right now on 30 servers. they are setup to ''immortal'' daemons : they try to aquire a lock on a well known file when starting and thus can simply be cron''d every 5 minutes. another way it to have script in init.d which does while true start_daemon Process::wait end in any case it''s proven largely unnecessary as i havn''t had any die for any reason other than our network totaly borking. the code is very stable - not to mention 100000 times easier to use than about any other distributed object lib out there. ;-) cheers. -a -- ==============================================================================| EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov | PHONE :: 303.497.6469 | When you do something, you should burn yourself completely, like a good | bonfire, leaving no trace of yourself. --Shunryu Suzuki ===============================================================================