3

I am doing some research on CDN providers, however I have a hard time finding out which ones are available, what exactly they offer, and if they are appropriate for my purpose. Hopefully you guys can give me some advice :-)

We are hosting a public REST API on an Amazon EC2 instance. Every call is dynamic and CPU intensive but generally activity is fairly stable. However regularly there are short, high peaks of many uses simultaneously requesting the same resource(s). This happens for example after someone blogs or twitters a link to a resource, and everyone clicks it.

Many resources don't change frequently and my server is sending explicit Cache-Control max-age headers specifying the time that every resource could and should be cached. I need a web cache / reverse proxy / CDN that does a good job with inspecting cache-control headers and caching these server calls, so that if 1000 clients request the same resource within a minute, my server only has to serve it once, or at least not a 1000 times.

Furthermore, the CDN should be able to cache any HTTP GET request, regardless of the content type or URI. Limitations of the file size are no problem; output is generally brief and compact. I was experimenting with Cloudflare today; however they only cache static files based on the 'file extension' of the URI, which makes it completely useless for most REST api's. And last but not least, I'm a small startup so preferably something that is affordable and scales both up and down.

Which are providers that might fit these requirements? Thanks for any experiences/advice.

Improve this question
2
  • Regarding my answer just now... I forgot to ask... what is the mime-type of the content resulting from the REST call? Depending on what the resulting resource/content is, it may not be worthwhile cost-wise. I believe you can load-balance within EC2's cloud, as I recall, which would give you greater ability to handle load-spikes, without having to use a CDN.
    – sandroid
    Jul 30, 2011 at 21:09
  • Although not a provider, setting up a pool of boxes running varnish-cache.org sounds like a good fit.
    – Tom
    Aug 4, 2011 at 15:13

3 Answers 3

Reset to default
3

Any CDN which is capable of "origin fetch" (that's the CDN industry term, most of us would call it a reverse proxy) should do what you need. Amongst low-cost, pay-per-use CDNs, I know these have that feature:

Note that Rackspace Cloud Files, which uses Akamai as a CDN, only supports static origin files uploaded to their servers.

One sticking point may be a minimum cache lifetime. Rapidly churning content creates issues for CDNs, which are designed to serve static content. So if you set "Cache-Control: max-age=5", a particular CDN might change that to some minimum value like 3600, or not cache it at all and simply pass the request back to your origin.

If none of the pay-per-use CDNs offer cache lifetimes as short as you need, you may have to look at contracted CDN service. Or, your best option will be to set up Varnish or Nginx to do caching on one or more of your EC2 instances.

Improve this answer
2

There are companies that specialize in API management services, including caching.

Two names of the top of my head:

  1. apigee
  2. Mashery

You may have more luck with them than a traditional CDN.

If you are looking for an in-house reverse caching proxy, then I think Varnish will do a good job.

Improve this answer
1

I can't speak for other/smaller CDN's, but I've worked with Akamai and Level3. I can tell you that Akamai can definitely cache by mime-type, or even wildcard-matching uri-stems. They can do pretty much everything you're looking for, I just don't know if you will find them to be within your budget.

Once through Akamai, if all requests are www.yoursite.com, and you wish to cache some, you need to rework your app a little, if you're looking to save costs. For instance, if you keep it at www.yoursite.com, all requests will begin to go through Akamai given that host is now redirected to an akamai host. Anything not configured to be cached will be proxied.

On the other hand, you can rename parts of your site such that your cookie is set with domain=*www.yoursite.com, and rewrite portions such that parts you wish to be cached are actuallyat host cdn.www.yoursite.com (or whatever, you get the idea). That means that anything you don't wish to be cached goes direct to origin, whereas anything that is in the cdn.www.yoursite.com subdomain is actually going to hit akamai. You'll need to make necessary arrangements on your origin server to accomodate this too no doubt.

Akamai has a billing option (if there even is another option for a site that sees hits measured only in the 1000's per day) that is bandwidth-based, and doing this can save you some coin.

All that said, to be honest, if you're talking about signifcant hits to resources that are static-ish (enough) to warrant cache-control, and it's only a question of thousands, you may be looking to solve the wrong problem. If these requests require a backend call on each request on your web-application, you should look at reworking that so that it's cached within the app and make the web-requests to such a resource less expensive.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .