Improve performance with a CDN

Introduction

What's a CDN.
A content delivery network or content distribution network (CDN) is a geographically distributed network of proxy servers and their data centers. The goal is to distribute service spatially relative to end-users to provide high availability and high performance.
CDN's were initially developed to reduce the bandwidth needed by the central server by installing proxies on different locations around the world.

Use case.

Assume that a user in Brazil is loading the homepage of a Chili server located in US, this user will normally need to download all the files from the server located in the US (71 files with a total size of 10 mb)
With the help of a CDN that has servers(endpoints) located in Brasilia, all the static files, images and JavaScript files will already have been cached due to the fact that another user in that region has already requested the files and can be delivered directly from the Brasilia endpoint to the customer (35 files).
As those files are locally cached in Brasilia those files will be delivered faster than if they should come from the US and they will not be requested to US server.
Main advantage of the CDN is clear in this use case:

• Offload delivery of static files to the servers that keep a copy of those files cached locally. That's the "edges" or "pop" of the CDN. => less requests on main server
• The User will receive those files more quickly as they are delivered from a server that is closer to him with less latency.

With this in mind it is clear that the big benefit for the user is that the website will load faster which will lead to a better user experience.

CDN concept

A CDN is like a transparent enterprise proxy with endpoints on geographical location spread all around the world with the unique goal to speed up the connection and unload bandwidth from the source server.
The Main advantage of the CDN is then to offload delivery of static files to the servers that keep a copy of those files locally. As the CDN is closer to the user than the origin server, the user receives the files more quickly.
Another nice optimization is that the majority of CDN implementations by default are delivering HTTP2 over HTTPS. HTTP2 is a new way of communication between the browser and the server that remove the limit of 6 concurrent download.
When a user has 70 files to download and can download only 6 at a time, being able to download 70 files simultaneously is a huge improvement.

CDN's also have a lot of optimizations like keeping session open to the servers, option to override expiration headers etc.…
CDN are used by ALL companies that have a medium to high workloads on the internet and/or have a global presence on the internet. They are fully transparent to the user and can even display custom error page when source server(s) are not available.

CDN Products

Many CDN's exist all over the world. The most common ones are CloudFlare, Akamai, MaxCDN, CDN77, CloudFront but many other exist. The following config description is based on Amazon AWS CloudFront configuration.

CDN configuration

Origin Server settings (Chili server)

If sensitive data is in transit between the customer and the Chili Server, it's a good practice to force HTTPS as protocol between the CDN and the Chili Server.
When no sensitive data transits between the browser and Chili Server, we recommend offloading SSL at the CDN and configure the CDN to connect to the Chili server over http.
If you are unsure about which type of transport you need, or you have a issue with HTTP to HTTPS or HTTPS to HTTP redirection, you can usually ask the CDN to follow the type of requests of the customer.
If requests are coming in http, the CDN will request in HTTP, if HTTPS backend connection are coming it will be done in HTTPS.
Don't forget that in all cases only HTTPS between the customer and the CDN can offer http2 and the best optimization. There is a possibility to keep using http, but enhancements will be limited.
If you have the option, please set the Timeout or Origin at 60 sec or even more (120 sec) if possible.
For AWS CloudFront, this example shows the typical configuration with a 60 sec timeout and HTTPS to HTTP offloading:

Offloading HTTPS to HTTP might be a problem if your website generate URL's based on the protocol. You must take into account the Origin protocol (type of request of the customer to the CDN) when generating a full link that contain the type of request (http/https).
CDN's are adding that information in the header between them and the Chili server.
This is can be found under "X-Forwarded-Proto" for CloudFront.
Documentation on this topic can be found here: https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/x-forwarded-headers.html#x-forwarded-proto
In the case of the Chili website, we can request https and offload https at the CDN.
Here are the additional headers that we set at CDN level to inform Chili that SSL offloading is in place and that the Chili Server must generate links with HTTPS even if the request is coming over HTTP.

Behaviors configuration

Behaviors in AWS CloudFront terminology are corresponding to Pages rules for Cloudflare, other CDN's might use other terminology but the goal is always the same : define rules that will match pages and define behavior of the CDN.
The following screen shows three different behaviors that we have configured for the Chili server.

The most important ones are related to /CHILI/ because those are related to Chili Editor. The other behaviors are related to files on the front-end and specific to each environment.

Behavior /CHILI/loading.gif

Behavior /CHILI/scripts/*.js

Behavior /CHILI/Spicybeerdemo_02/icon.aspx

Behavior /CHILI/Spicybeerdemo_02/download.aspx

Default Cache Behavior Settings

CloudFormation Template

If you want to deploy the full configuration quickly you can use the following CloudFormation template :
https://s3.eu-central-1.amazonaws.com/beercompany-awsfiles/cloudformation/BeerCompanyCD Nv1.template
This CloudFormation template will create:

• CloudFront distribution and output his cname as output, you must take that output and update your main DNS with this value.
• Origin server for Chili Service under /Chili/ part of your main domain name.
• Origin server for Web server that covers all the rest that are not under /Chili/
• ApiGateway that link to a Lambda function to clear the cache.
• All the behaviors that are running for the Chili server. You can update them if you want, check with Chili team if you want to update values under /Chili/
• Create one S3bucket for logging (not fully used now)