Johnathan.org

Showing only: cloudflare

Cloudflare Argo: 228 Days Later

It seems like such a random amount of time to review (and it kind of is) but I wanted to start of 2019 right and review a topic I touched on in 2018: Cloudflare‘s smart-routing product, Argo.

In my previous post about Argo, I covered the vast improvements to response times just by enabling the service. Response times were practically cut in half. Since then, I’ve made some more tweaks to my site so it felt fair to review if Argo is still picking up the slack it claims to. If you’re unsure of how Argo works, my previous post has a good explainer.

Considering Aggressive Caching

One improvement I made was to lean heavy on Cloudflare’s Page Rules functionality. I purchased myself a set of five Rules for an additional +$5.00/month and got to work. I focused on wielding caching for everything that isn’t likely to change often if ever. In this case, most static assets will live on Cloudflare’s servers and in a visitor’s browser for quite a while.

When I first implemented this, I didn’t consider plugin JS, but in reality, most of what’s being caught by that rule is WordPress-related (read: Jetpack), and I haven’t experienced issues thus far.

With the majority of /wp-content being taken care of with page rules, it was time to re-evaluate the now decreased load and its effect on the benefits Argo provides.

Argo Post-Aggressive Caching

There’s a reason Cloudflare recommends Argo regardless of how you cache. Even with aggressive caching in place, I’m still seeing about 25% response time improvements:

The average runs between 23-27%, depending on the days I’m checking, but the 23.28% in the image above is pretty close to “most of the time.” What’s also worth pointing out is the peaks and valleys largely follow the same percentage improvement across the board, and it’s no wonder: 75% of requests end up going through Argo’s pipeline.

With the aggressive Page Rules and Argo, I’m comfortable in saying Argo has a permanent home with this site and any future projects I take on. It’s a no-brainer and still remains highly cost-effective.

Busting Cloudflare Cache when Posting to WordPress via XML-RPC

I love Cloudflare. I’ll come right out and say that now. It’s a great service and makes for incredibly performant sites if used right (aggressively). I don’t feel like I’m getting the most out of it until it’s caching just about everything possible. Most of my content is static and never changes (save for the home page and each paginated set of posts thereafter). Even then, the homepage changes maybe a couple times a day. It makes a lot of sense for Cloudflare to cache them all. I use pretty aggressive Page Rule-based caching to accomplish that.

Part of my regular blogging workflow involves posting using MarsEdit. It’s a great tool and uses XML-RPC to post content. One of the problems with this workflow is that most caching-management plugins for WordPress don’t consider any kind of content changes via XML-RPC, only via the WordPress Admin UI. This means that there’s virtually no support for engaging all the cache-cleaning activities when XML-RPC events take place and thus Cloudflare is never notified for purging.

Luckily, there’s a solution to this problem. It involves a bit of duct-tape-like hooking into core WordPress, but in my testing, it’s been pretty painless, and posting doesn’t seem to be noticeably slower (XML-RPC posting takes a few seconds, anyway, adding another second isn’t a big deal, in my opinion). All we need to do is add a filter to xmlrpc_publish_post.

Sounds easy, you say? It is!

function clear_cache() {
$curl = curl_init();
curl_setopt ($curl, CURLOPT_URL, CACHE_PURGE_URL);
curl_exec ($curl); curl_close ($curl);
}

add_filter( 'xmlrpc_publish_post', 'clear_cache');

I set CACHE_PURGE_URL in wp-config.php to be a local path that when triggered with a GET request, makes a POST request that looks like the equivalent of this CURL request:

curl -X POST "https://api.cloudflare.com/client/v4/zones/YOUR_ZONE_ID/purge_cache" \
-H "X-Auth-Email: YOUR_EMAIL_ADDRESS" \
-H "X-Auth-Key: YOUR_API_KEY" \
-H "Content-Type: application/json" \
--data '{"purge_everything":true}'

Replace YOUR_ZONE_ID, YOUR_EMAIL_ADDRESS, and YOUR_API_KEY and you’re set.

By making this request after xmlrpc_publish_post using add_filter(), we’ve already established our updated content so the trigger will have Cloudflare pull the freshest and not accidentally re-pull stale bits.

Right now, it’s an entry in my theme’s functions.php. If I was to do this truly right, I’d make this a plugin. Someday!

A Week of Cloudflare Argo

I recently made a pretty heavy shift over to Cloudflare. The majority of assets and HTML on this site load from Cloudflare’s servers now, instead of my own. The only time this differs is when I push changes up to its GitHub repo. The last step in the build process after deploying to my server is hitting the API and requesting a complete cache dump. I could be more programmatic about it but updates aren’t frequent enough to warrant a more careful approach.

On its own, Cloudflare’s caching and CDN is great, but there’s another piece that makes it even better. Argo is Cloudflare’s smart routing feature that makes real-time choices about the best path to take from the Cloudflare POP (point of presence) to the origin (my server). This can dramatically reduce requests that do have to make their way to my San Francisco-located server.

It’s $5 a month plus $.10 per GB. Since most of the content on this site is text and a smattering of images, I’m not concerned with the price and $5 is fun money, basically. I saved that moving from DNSimple to Cloudflare for DNS, too, so there’s that.

Looking at some of the stats, now…

As reported by Updown.io (the service that powers status.johnathan.org and the uptime percentage at the bottom of the page), the majority of my requests come in in no time at all, with the obvious winner being Los Angeles (closest to San Francisco, my DigitalOcean location). The outlier is France, though I’m not too concerned with it. It seems to be fluctuating.

(Update May 24, 2018: I noticed response times from Updown.io had dropped to sub 100ms averages thanks to France falling in line with the rest of the countries. The only outlier at this point is Sydney’s lookup taking 3-9x longer) than the other locations.)

Moving over to Pingdom

It’s pretty obvious when Argo was enabled. I’m not sure what happened with the spike half-way between the 16th and 17th, but a response time being cut in half is amazing, even after doing zero work on the server, itself.

Lastly, the Cloudflare stats…

We see a clear difference in their metrics of response time improvements. Including the entire TLS handshake process, these sub 200ms response times in most cases is wonderful. At scale, Argo would have the potential to be mind-numbingly fast.

I’ll continue to use Argo for the foreseeable future. Cloudflare is free and works great for hobbyists like myself. Argo is $5 + $0.10/GB and I’d consider that peanuts. If it’s of any help, I’ve sent maybe 50MB through it since I signed up a week ago (remember, mostly text and a few images).

Johnathan Lyman
Kenmore, WA,
United States
 
blogging, design, technology, software, development, gaming, photography