Recommendations for Caching/CDN

Using one or more CDNs is crucial when delivering streams at scale, especially when the audience is distributed across regions. The CDN will act as a reverse proxy cache, caching HTTP GET requests: initial hits will reach Origin, but any subsequent requests for the same content will hit the CDN, thereby offloading Origin considerably and making sure the content is as close to customers as possible.

Using multiple CDNs, failures on the CDN can be avoided, and for optimum performance it may even be worthwhile to choose the CDN to route a request through on a per-request basis, making sure the most performant route is taken. Specific third-party tooling is available to support such use cases.

Warning

Some CDNs support splitting requests into multiple range requests, this must not be enabled for requests to Origin, as it will cause unnecessary extra CPU load and storage I/O as the Origin still has to produce the entire segment.

Note

Origin does not support push based transfer of content to CDNs. In general, we do not recommended this approach either, as it may be unclear what content needs to be pushed and your content's footprint on the CDN might become very large, especially for VOD use cases. However, if you do want to take this approach you can do so for VOD using Unified Packager instead of Origin.

The only actual must fix in the following scenario's is Decrease upstream traffic. The other scenario's might or might not apply to your setup.

• Origin shield cache
  • Use case support per proxy server (Apache, Nginx, Varnish)
  • Load testing

• Use cases
  • Decrease upstream traffic
  • HTTP response headers
  • Prefetching of content
  • Handle upstream server's limited lifetime
  • HTTP response codes
  • Content aware key caching
  • Mitigate malicious requests
  • Cache invalidation/purge
  • Redundant origin shield cache

• Common Media Server Data
  • Example configurations