# High availability through ARes + caching

**URL:** <https://www.ruby-forum.com/t/high-availability-through-ares-caching/118673>\
**Category:** Rails\
**Created:** [October 29, 2007, 11:10pm UTC](https://www.ruby-forum.com/t/high-availability-through-ares-caching/118673 "2007-10-29T23:10:26Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![pergesu](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/22d042/32.png) [@pergesu](https://www.ruby-forum.com/u/pergesu)\
**Post date:** [October 29, 2007, 11:10pm UTC](https://www.ruby-forum.com/t/high-availability-through-ares-caching/118673/1 "2007-10-29T23:10:26Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![pergesu](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/22d042/32.png) [@pergesu](https://www.ruby-forum.com/u/pergesu)\
**Post date:** [October 30, 2007, 12:19am UTC](https://www.ruby-forum.com/t/high-availability-through-ares-caching/118673/2 "2007-10-30T00:19:26Z")

</div>

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:

> **[Advanced Rails Caching.. on the Edge](http://revolutiononrails.blogspot.com/2007/08/advanced-rails-caching-on-edge.html)**
>
> When trying to scale a portal to millions of users with complex personalization, we had to rethink the application design. We needed partial...

-Ben

---

<div class="post-metadata">

**Author:** ![pergesu](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/p/22d042/32.png) [@pergesu](https://www.ruby-forum.com/u/pergesu)\
**Post date:** [October 30, 2007, 12:26am UTC](https://www.ruby-forum.com/t/high-availability-through-ares-caching/118673/3 "2007-10-30T00:26:27Z")

</div>

On Oct 29, 2007, at 3:10 PM, Pat M. wrote:

> server, with its own small sqlite database. When a request comes in,
> 
> 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

Pat-

I’d recommend taking a look at varnish  
[http://varnish.projects.linpro.no](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