Content Delivery Network : Handshake with Liferay

Content is at the heart of every system in this cutting-edge digital world and no doubt, every individual in this fraternity has to deal with it on a day-to-day basis. Classification of this content like static, dynamic, structured, unstructured- defines system boundaries many-a-times and plays a vital role in providing top-notch digital experience to the end user.  However, delivering this content with high performance and high availability is really crucial to maintain this experience and keep your end users happy.

Most of the time, this content includes JavaScript, CSS, Images and other resources which are static in nature and heavier in size. And if such heavy content is to be made accessible faster across the globe then one definitely needs to consider the distance for the data to travel between origin and destination. 

Having single server node sitting in one corner of the world delivering content to the user sitting in the opposite corner will definitely incur delays due to network latency. That is precisely where content delivery networks come into picture – by providing alternative server nodes which are geographically closer to the user enabling faster response and download time of the content.

The diagram below provides a quick view of Content Delivery Network (CDN) –

Origin Content Provider – origin server (for this blog – we can consider it as Liferay server)

CDN Provider – selects replica server to serve the requested objects/resources to the end user

Replicated server – serves the content to the end user based on the request. Content is pushed/pulled from origin server on/by replicated servers through CDN provider

Users – entities requesting contents.

 

CDN Request Routing

Every CDN contains a request routing system which is responsible for directing client requests to an appropriate replicated web server for the delivery of the content. Following diagram shows how this request routing happens within CDN –

The overall request routing flows like this – User requests content from the origin server by providing its URL in the browser. Upon receipt of the request, the origin server decides to send skeleton/basic index page back to user and propagate the request to the CDN provider to fetch requested embedded objects/resources. CDN provider based on the selection algorithm decides on the closest replica server, which serves the requested resource to the end user.

Liferay and CDN : Handshake

Though Liferay can be configured to work with CDN, Liferay does not have a provision out of the box to upload static resources (like CSS, JS, Images) on Content Delivery Networks. In order to upload static resources from portlets, themes and hooks on CDN, a custom component needs to be built. However, modern day CDNs (like AKAMAI) have capability to dynamically retrieve content from underlying origin servers and Liferay works with them seamlessly.

The diagram below shows how the handshake of Liferay and Content Delivery Network happens- 

Usually, Content Delivery Network is established as interceptor proxy within architecture. It sits between end user and Liferay portal server.  Every resource request being made by end user is intercepted by the CDN first, to deliver the resource. The overall request flows like following -

  • User sends a request through web client / web browser.
  • The request is received by Liferay Main Servlet which in turn triggers Liferay events (including ServicePreAction) upon reception of the request.
  • ServicePreAction Event checks if Liferay is configured to enable CDN to serve resources.

a.       Following properties need to be configured to enable CDN

  • CDN Host HTTP (retrieve content via CDN for requests made over HTTP protocol)
  • CDN Host HTTPS(retrieve content via CDN for requests made over HTTPS protocol)
  • CDN Dynamic Resources Enabled (to serve dynamically generated CSS, JS, images via CDN)
  • Once CDN is configured, ServicePreAction event checks every resource being delivered as a pat of the response and replaces the host name with specified CDN host.
  • Liferay Main servlet then sends this skeleton response back to the browser with newly generated URLs for resources
  • Upon reception of the skeleton response, browser requests resources from specified CDN.
  • If the resource does not exist on CDN, then CDN retrieves resources from underlying origin server
  • Once retrieved, CDN consequently serves the resource request.
  • The resource is then cached on replia servers for subsequent request serving

Most of CDNs and related Replica servers have a provision to configure dynamic retrieval of these resources (like CSS, JS, Images) from underlying origin server i.e. Liferay portal server. They also have a periodic provision to invalidate cached resources so that new content can be pushed to the client as an when it changes on the origin server.

Benefits of CDN –

  • Reduced Latency - Delivering content as quickly as possible ensuring shortest distance for data to travel. Serving content from servers which ae geographically closer to the end user.
  • More Parallel Downloads – Using multiple subdomains concept (domain sharding) of CDNs for handling resources enables faster and parallel downloads of resource resulting in faster performance.
  • Effective Browser Cache – Caching from the same CDN and using it for different sites. When browser picks up one coomon library like Jquery from commonly used CDN, it caches that file. If some other website requests same file from the same CDN, then this request is served with the same cached version of the file making it available faster.

Liferay with CDN: When to Use and Not to Use (Most Idle scenarios)

 

  • Building site for Geographically Distributed user base

  • Dynamic Data vs Static Data

  • Intranet/Intenal Application

  • Sites targetted at Mobile Devices (Depends on use case basis)

Choosing CDN for Sites targeted at mobile devices depends on use case basis, as content being delivered through mobile also have to consider other factors like provider network, network speed and latency introduced at data provider/receptor end.

 

Conclusion

CDN these days play a crucial part of the overall architecture in order to deliver the faster digital experience to end users. However, implementation of these CDN depends on websites goals, preferences, priorities and cost. The power of CDN can make and break your websites. So make your choice wisely while implementing one!!!

Blogs
Very well explained Rahul. I have a question about content upload on CDN, as you mentioned about custom component, do you have any reference of such kind of liferay plugin which is available on marketplace/github?
Well - not that i am aware of!
Nevertheless - as I mentioned, these days, we do not need to build such components because most of the CDNs already provide configurations to dynamically retrieve content from underlying Origin server.
Thanks for sharing Rahul--This blog gives very good understanding of CDN with Liferay. How ServicePreAction identify that particular resource in a plugin need to be served as static resource and append CDN url?
Hi Sushil, have a look on initThemeDisplay() method in ServicePreAction. It set CDN host in ThemeDisplay object if CDN is configured in portal.
When we use themeDisplay.getPathThemeJavaScript() or getPathThemeImages, it return path with CDN url.

You can have a look on these github pages for more details:
https://github.com/liferay/liferay-portal/blob/6.2.x/portal-impl/src/com/liferay/portal/events/ServicePreAction.java#L152
https://github.com/liferay/liferay-portal/blob/6.2.x/portal-service/src/com/liferay/portal/theme/ThemeDisplay.java#L1024
AKAMAI has the capability to dynamically retrieve content from underlying origin servers and Liferay works with them seamlessly.

In this scenario, do we need to setup

- CDN Host HTTP
- CDN Host HTTPS
- CDN Dynamic Resources Enabled

exclusively in Liferay?

In my understanding, for AKAMAI we do not need to setup these parameters. Please guide.