We have an app with two distinct parts: a publish console and then a read-only view part. The views account for over 99% of our traffic, and the content doesn''t change very much. We want to build a HA system for our views. The obvious first step is to split out the publishing from the viewing. I''m wondering what''s the best way to handle data on the view servers though. The two ideas I''ve had both involve using ActiveResource...the first is to run the view server as a caching server, with its own small sqlite database. When a request comes in, it looks to see if it has the data. If so it just builds and returns the page. If not, it makes an ARes request to our main servers, gets the data, and sticks it in its own db before serving it up. When data changes on the server, we just send an HTTP DELETE to the view server to expire the cached content. The other idea I had was to bypass a db on the view server, and stick a regular HTTP caching server in between the view and publish servers. This way a view server only makes HTTP requests, and squid (or whatever) handles the actual caching. I''d appreciate any thoughts on perceived pros and cons of these two approaches, and I''d certainly love to hear any other ideas. Pat --~--~---------~--~----~------------~-------~--~----~ 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?hl=en -~----------~----~----~----~------~----~------~--~---
I think your second idea sounds the easiest and fastest solution. I also don''t see any downsides in using a regular HTTP caching engine (but I may not understand your situation entirely.) Caching mechanisms already exists so I don''t think you need to reinvent one with ARes. If you do down that HTTP caching route you may want to look into ESI to avoid reinventing the wheel: http://revolutiononrails.blogspot.com/2007/08/advanced-rails-caching-on-edge.html -Ben Pat Maddox wrote:> We have an app with two distinct parts: a publish console and then a > read-only view part. The views account for over 99% of our traffic, > and the content doesn''t change very much. We want to build a HA > system for our views. > > The obvious first step is to split out the publishing from the > viewing. I''m wondering what''s the best way to handle data on the view > servers though. The two ideas I''ve had both involve using > ActiveResource...the first is to run the view server as a caching > server, with its own small sqlite database. When a request comes in, > it looks to see if it has the data. If so it just builds and returns > the page. If not, it makes an ARes request to our main servers, gets > the data, and sticks it in its own db before serving it up. When data > changes on the server, we just send an HTTP DELETE to the view server > to expire the cached content. > > The other idea I had was to bypass a db on the view server, and stick > a regular HTTP caching server in between the view and publish servers. > This way a view server only makes HTTP requests, and squid (or > whatever) handles the actual caching. > > I''d appreciate any thoughts on perceived pros and cons of these two > approaches, and I''d certainly love to hear any other ideas. > > Pat > > > >--~--~---------~--~----~------------~-------~--~----~ 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?hl=en -~----------~----~----~----~------~----~------~--~---
On Oct 29, 2007, at 3:10 PM, Pat Maddox wrote:> > We have an app with two distinct parts: a publish console and then a > read-only view part. The views account for over 99% of our traffic, > and the content doesn''t change very much. We want to build a HA > system for our views. > > The obvious first step is to split out the publishing from the > viewing. I''m wondering what''s the best way to handle data on the view > servers though. The two ideas I''ve had both involve using > ActiveResource...the first is to run the view server as a caching > server, with its own small sqlite database. When a request comes in, > it looks to see if it has the data. If so it just builds and returns > the page. If not, it makes an ARes request to our main servers, gets > the data, and sticks it in its own db before serving it up. When data > changes on the server, we just send an HTTP DELETE to the view server > to expire the cached content. > > The other idea I had was to bypass a db on the view server, and stick > a regular HTTP caching server in between the view and publish servers. > This way a view server only makes HTTP requests, and squid (or > whatever) handles the actual caching. > > I''d appreciate any thoughts on perceived pros and cons of these two > approaches, and I''d certainly love to hear any other ideas. > > PatPat- I''d recommend taking a look at varnish http://varnish.projects.linpro.no . It''s a sweet caching proxy built for situations like these. It has a programmable caching interface via VCL. For cached content like this you are always better off if you can get it served without doing a database lookup imho. Cheers- -Ezra --~--~---------~--~----~------------~-------~--~----~ 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?hl=en -~----------~----~----~----~------~----~------~--~---