Should we configure plugins for each route or one for a service?

Questions
1

We have a custom kong plugin that needs to now support different configurations based on a http header value. There are two approaches to this

  1. Modify the plugin to support multiple configurations instead of one value right now. It will read the header value and act accordingly
  2. Define multiple routes with the same path and different header values. Each route is configured with the plugin that has a unique configuration

The advantage of the second approach is clear that we don’t need any code modifications in the plugin and it remains simple. My worry is would it have any effect on kong’s performance.

What is the impact of configuring one plugin at the service level vs multiple plugins for each route? Which of these is most efficient?

Below is a sample config demonstrating the problem

Approach 1

services:  
  - name: local-leads-app
    url: http://localhost:8080/api/leads/v1
    routes:
      - name: local-leads-app-route
        paths:
          - /api/leads/v1
        strip_path: true
    plugins:
      - name: custom-rate-limiting
        config:
          minute: ["x_user_id_v1_50", "x_user_id_v2_100"]
          policy: local

Approach 2

services:
  - name: local-leads-app
    url: http://localhost:8080/api/leads/v1
    routes:
      - name: local-leads-app-route-1
        paths:
          - /api/leads/v1
        strip_path: true
        headers:
          x-user-id: [ "v1" ]
        plugins:
          - name: rate-limiting
            config:
              minute: 5
              policy: local
      - name: local-leads-app-route-2
        paths:
          - /api/leads/v1
        strip_path: true
        headers:
          x-user-id: [ "v2" ]
        plugins:
          - name: rate-limiting
            config:
              minute: 100
              policy: local

Thanks.

2 Likes
2

I’ve always taken the approach of using a plugin on the service if you need the same behavior irrespective of route or consumer. Assuming “modify the plugin” means creating a new bespoke one, then you’re taking on the burden of maintaining it (including debugging it when it’s not working as you expected) which may be more complex and costly in the long run compared with just configuring out-of-the-box plugins on multiple routes.

1 Like
3

Right, I am also of the impression that configuring the same plugin for multiple routes would better.

I am worried if this would mean loading multiple instances of the plugin in memory leading to some inefficiencies. Any insights into this?

Thanks.

4

I’m not that familiar with the inner workings of how Kong (really NGINX) executes plugin code, but I would be surprised if running a given plugin on a couple of routes vs. on the service would be a big resource drain. If you’re running your Kong environment so close to the bone, your bespoke alternate solution might be even more complex to develop/maintain if has to run in a such a minimal footprint.

To get more insight into the performance implications of multiple instances of a plugin, you might also pose your question to the discussions section of the Kong GitHub repo.

1 Like
5

That’s a great idea. Thanks @shawnc1959-8451.
I have started a discussion on the github repo