Content-cache can be used to deploy your own content distribution network (CDN) and provides:
- Full end-to-end encryption - TLS/SSL termination both between clients and caching frontends as well as between CDN and backend servers.
- Caching - objects are to be cached and stored locally to reduce network bandwidth to shared infrastructure and reduce load. Note that currently the cache is provided on a per-unit basis, and is not shared between deployed units.
In a content-cache deployment, each unit is composed of HAProxy frontend which forwards traffic to Nginx. Nginx then forwards traffic to an HAProxy backend and from there traffic is forwarded to the upstream site as configured in the sites configuration option.
This architecture was chosen after extensive performance and feature testing of the following possible solutions:
- Squid
- HAProxy & Squid
- Nginx
- HAProxy & Nginx
- HAProxy & Nginx & HAProxy
- HAProxy & Varnish HTTP Cache & HAProxy
- Hitch & Varnish HTTP Cache & HAProxy
When testing against large files ( ~100MB), both Nginx and HAProxy & Squid solutions faired equally. However, for smaller files (~32kbytes), the Nginx solution seemed to be a better choice - lower overall system load with Nginx processes consuming less CPU time than HAProxy for SSL/TLS termination.
Nginx was chosen due to better overall performance and features than the others. However, the Open Source version of Nginx only provides very basic metrics, therefore content-cache was designed with HAProxy on either side of it. This allows for detailed metrics about traffic to and from each unit.
Navigation
| Level | Path | Navlink |
|---|---|---|
| 1 | Architecture | |
| 1 | contributing | Contributing |
| 1 | sites-configuration | Sites Configuration |
| 1 | sites-secrets-configuration | Sites Secrets Configuration |
Redirects
Mapping table
| Path | Location |
|---|