High availability through ARes + caching

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.


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:



Pat Maddox wrote:


  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.