Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Frontcache: Cache for Dynamic Pages

DZone's Guide to

Frontcache: Cache for Dynamic Pages

Learn how to speed up your site for users, by implementing an application that differentiates between real users and bots when caching.

· Web Dev Zone
Free Resource

Start coding today to experience the powerful engine that drives data application’s development, brought to you in partnership with Qlik.

A lot of applications use Content Delivery Network [CDN] for static content (images, CSS, JS, etc). It really makes your site faster and reduces the load on your servers a lot.

A similar approach can work for dynamic pages as well: static parts of the page are cached, so dynamic parts of the page hit servers only. It can speed up your website a lot and reduce backend load times! It's something Frontcache is designed for.

Page structure example

For example for ‘Product details’ page cart and recommendation parts are dynamic only, so the rest part of the page can be cached.

Another good catch is that Frontcache returns a single response for the browser. No need to handle multiple RESTful calls with fancy JavaScript and debug it for different browsers' versions.

Frontcache differentiates between HTTP requests from users versus those from bots (Googlebot, Bingbot, Baiduspider, etc). So, the same ‘Product details’ page can be handled entirely from the cache for bots but has dynamic data for customers. 

And it’s really easy to integrate, regardless of the programming language you use (Java, PHP, .Net, etc). It can be used as a standalone edge in a corporate network or as servlet filter (for Java-based websites) or as a distributed cluster of edges similar to CDN networks.

Some Use Cases

Scale legacy systems for larger traffic load (including loads from bots). Legacy systems are very sensitive to the amount of concurrent traffic. A little bit higher traffic rate during hot hours can slow down the whole system a lot (even move it out of service). With Frontcache, legacy systems can be scaled up by a dozen times with minimal code change. 

Cache ‘heavy’ backend requests (e.g. report generation). For example, the system generates documents in PDF format and it takes a couple seconds to complete the request. Impatient operators want to get the page faster and refresh it a couple more times - but this will slow down the whole system a lot (even move it out of service). Frontcache is designed to shield such sensitive components with fault tolerance tuning and short time caching. 

Increase website performance without frontend development overhead. Nowadays, to speed up page download times, the following approach is used: after the page is loaded, multiple JavaScript/RESTtful calls make up a page’s content. The downside of such an approach is that it support multiple browsers with different versions which leads to bugs and extra development/support. With Frontcache, the same dynamic page can be loaded fast in a single response (without extra complexity with JavaScript/RESTful calls). 

Sounds like your case? There are ‘Getting Started’ article and code samples on Github.

How it Works

General request processing overview:
A request is checked in the cache. If no data is in the cache - hit the origin.
The response is checked for SSI (server side includes). When a response has been included - they are resolved from the cache/origin.
Completed response is sent back to the client.

Frontcache overview

Pages for the example above have the following markup:
Page includes


Fun Demo

www.coinshome.net uses Frontcache and posts real-time statistics online.
It's fun to create load and check how it's handled in real time:

1. Download the sitemap from https://www.coinshome.net/export/sitemap.txt

2. Create a crawler - as an example, I've included the following bash script (crawler.sh):

#!/bin/bash

while IFS='' read -r line || [[ -n "$line" ]]; do
echo "crawling $line"
curl -H "Accept: text/html" -H "Accept-Encoding: gzip, deflate" -H "User-Agent: Googlebot" -o output.log $line
done < "$1"

3. Run the crawler.

./crawler.sh sitemap.txt

Check how it works online

Notice:

 - Pages have a 'recent updates' section with frequently changed content.
- The 'logs to headers' feature is enabled and response headers have to trace how the page was assembled.

page assemble logs


Cheat Sheet With Features/Key Points

  • Page fragment cache.

  • User agent specific caching (user vs bot).

  • Written in Java, and works with any language (Java, PHP, .Net, etc).

  • Fault tolerance management (based on Netflix Hystrix).

  • Advanced error handling with fallback configurations for URL patterns.

  • Advanced web based console for configs and real-time monitoring.

Create data driven applications in Qlik’s free and easy to use coding environment, brought to you in partnership with Qlik.

Topics:
cache ,java ,web dev

Published at DZone with permission of Serhiy Pavlikovskiy. See the original article here.

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}