Improve Performance with Proxy Caching

In this topic, you’ll learn how to use proxy caching to improve response efficiency using the Proxy Caching plugin.

If you are following the getting started workflow, make sure you have completed Protect your Services before continuing.

What is Proxy Caching?

Kong Gateway delivers fast performance through caching. The Proxy Caching plugin provides this fast performance using a reverse proxy cache implementation. It caches response entities based on the request method, configurable response code, content type, and can cache per Consumer or per API.

Cache entities are stored for a configurable period of time. When the timeout is reached, the gateway forwards the request to the Upstream, caches the result and responds from cache until the timeout. The plugin can store cached data in memory, or for improved performance, in Redis.

Why use Proxy Caching?

Use proxy caching so that Upstream services are not bogged down with repeated requests. With proxy caching, Kong Gateway can respond with cached results for better performance.

Set up the Proxy Caching plugin

Using Kong Manager

Using the Admin API

Using decK (YAML)

  1. Access your Kong Manager instance and your default workspace.

  2. Go to API Gateway and click Plugins.

  3. Click New Plugin.

  4. Scroll down to the Traffic Control section and find the Proxy Caching plugin.

  5. Click Enable.

  6. Select to apply the plugin as Global. This means that proxy caching applies to all requests.

  7. Scroll down and complete only the following fields with the parameters listed.

    1. config.cache_ttl: 30
    2. config.content_type: application/json; charset=utf-8
    3. config.strategy: memory

    Besides the above fields, there may be others populated with default values. For this example, leave the rest of the fields as they are.

  8. Click Create.

Call the Admin API on port 8001 and configure plugins to enable in-memory caching globally, with a timeout of 30 seconds for Content-Type application/json.

cURL

HTTPie

  1. curl -i -X POST http://<admin-hostname>:8001/plugins \
  2. --data name=proxy-cache \
  3. --data config.content_type="application/json; charset=utf-8" \
  4. --data config.cache_ttl=30 \
  5. --data config.strategy=memory
  1. http -f :8001/plugins \
  2. name=proxy-cache \
  3. config.strategy=memory \
  4. config.cache_ttl=30 \
  5. config.content_type="application/json; charset=utf-8"
  1. In the plugins section of your kong.yaml file, add the proxy-cache plugin with a timeout of 30 seconds for Content-Type application/json; charset=utf-8.

    1. plugins:
    2. - name: proxy-cache
    3. config:
    4. content_type:
    5. - "application/json; charset=utf-8"
    6. cache_ttl: 30
    7. strategy: memory

    Your file should now look like this:

    1. _format_version: "1.1"
    2. services:
    3. - host: mockbin.org
    4. name: example_service
    5. port: 80
    6. protocol: http
    7. routes:
    8. - name: mocking
    9. paths:
    10. - /mock
    11. strip_path: true
    12. plugins:
    13. - name: rate-limiting
    14. config:
    15. minute: 5
    16. policy: local
    17. - name: proxy-cache
    18. config:
    19. content_type:
    20. - "application/json; charset=utf-8"
    21. cache_ttl: 30
    22. strategy: memory
  2. Sync the configuration:

    1. deck sync

Validate Proxy Caching

Let’s check that proxy caching works. You’ll need the Kong Admin API for this step.

Access the /mock route using the Admin API and note the response headers:

cURL

HTTPie

  1. curl -i -X GET http://<admin-hostname>:8000/mock/request
  1. http :8000/mock/request

In particular, pay close attention to the values of X-Cache-Status, X-Kong-Proxy-Latency, and X-Kong-Upstream-Latency:

  1. HTTP/1.1 200 OK
  2. ...
  3. X-Cache-Key: d2ca5751210dbb6fefda397ac6d103b1
  4. X-Cache-Status: Miss
  5. X-Content-Type-Options: nosniff
  6. ...
  7. X-Kong-Proxy-Latency: 25
  8. X-Kong-Upstream-Latency: 37

Next, access the /mock route one more time.

This time, notice the differences in the values of X-Cache-Status, X-Kong-Proxy-Latency, and X-Kong-Upstream-Latency. Cache status is a hit, which means Kong Gateway is responding to the request directly from cache instead of proxying the request to the Upstream service.

Further, notice the minimal latency in the response, which allows Kong Gateway to deliver the best performance:

  1. HTTP/1.1 200 OK
  2. ...
  3. X-Cache-Key: d2ca5751210dbb6fefda397ac6d103b1
  4. X-Cache-Status: Hit
  5. ...
  6. X-Kong-Proxy-Latency: 0
  7. X-Kong-Upstream-Latency: 1

To test more rapidly, the cache can be deleted by calling the Admin API:

cURL

HTTPie

  1. curl -i -X DELETE http://<admin-hostname>:8001/proxy-cache
  1. http delete :8001/proxy-cache

Summary and Next Steps

In this section, you:

  • Set up the Proxy Caching plugin, then accessed the /mock route multiple times to see caching in effect.
  • Witnessed the performance differences in latency with and without caching.

Next, you’ll learn about securing services.