perf(pdk): refine with optional cache to improvement performance

[ProBrian]

Summary

Checklist

• The Pull Request has tests
• A changelog file has been created under changelog/unreleased/kong or skip-changelog label added on PR if changelog is unnecessary. README.md
• There is a user-facing docs PR against https://github.com/Kong/docs.konghq.com - PUT DOCS PR HERE

Issue reference

Fix #[issue number]

[ProBrian]

http_get_header supports ctx param to cache headers, expose it to get_header API so we could use cache.

[bungle]

I don't like this either. If we add this parameter, we need to always keep the API like that, that the second parameter needs to be ctx. The benefits are so small that I would rather not do it. The most of the changes in plugins seems to be utilizing this. And that is also I think somewhat "bad" code to make people create tables of ctx and pass it here. If we cannot find better way to do this, then I would not do it.

Just an example e.g. if someone wants to add more beneficial parameter lilke default in case the header is missing the code would become:

local value = kong.request.get_header("Some-Header", nil, "default")

Perhaps we will never add that either, but just tells that we don't want these strange ctx parameters in public API.

[ProBrian]

What if we use kong.tools.get_header(name, ctx) directly in plugins, to replace non-cached kong.request.get_header API in certain places to achieve the cache benefit? It must be better to use PDK APIs in plugins, but I do see that there are a lot of kong.tools usage in plugins(which I feel more like should be used "internally" in core or some non-plugin module?), Do you think it's a proper practice?

[bungle]

@ProBrian In general it would be best if we can get to state where there is no require "module" statements in plugins. That is we have a powerful PDK. But meanwhile, yes, many plugins require different modules. That also then spreads to all custom plugins as plugins are copy pasted. That then will make all our internal APIs and tools public too which we cannot break. I think for example those plugins, just call get_headers once and work with headers and call it done, rather than pass a table to somewhere that something else caches the get_headers.

[ProBrian]

just a minor refinement so that if we could reduce the reads of ngx.ctx.buffered_proxying by passing it by param

[ProBrian]

Use a local ctx here which is cheaper thanngx.ctx, and the cache is only fresh in the local ctx lifetime, not in the request lifetime, so we don't need ngx.ctx

[bungle]

Let's revert all the API changes and related changes in where the changed APIs were used. Benefit vs. drawbacks are too small. Those optimizations can be implemented inside plugins themselves if they are that good. In many cases it also depends whether plugin is reading single or multiple headers to what to use, eg. is. get_headers better than multiple get_header and is multiple get_header better with created context table at what count?

[bungle]

I don't like this either. If we add this parameter, we need to always keep the API like that, that the second parameter needs to be ctx. The benefits are so small that I would rather not do it. The most of the changes in plugins seems to be utilizing this. And that is also I think somewhat "bad" code to make people create tables of ctx and pass it here. If we cannot find better way to do this, then I would not do it.

Just an example e.g. if someone wants to add more beneficial parameter lilke default in case the header is missing the code would become:

local value = kong.request.get_header("Some-Header", nil, "default")

Perhaps we will never add that either, but just tells that we don't want these strange ctx parameters in public API.

[ProBrian]

Let's revert all the API changes and related changes in where the changed APIs were used. Benefit vs. drawbacks are too small. Those optimizations can be implemented inside plugins themselves if they are that good. In many cases it also depends whether plugin is reading single or multiple headers to what to use, eg. is. get_headers better than multiple get_header and is multiple get_header better with created context table at what count?

Removed all public API changes. @bungle

[bungle]

@ProBrian I'll setup a meeting, where we can discuss how to get this in.

[chronolaw]

Do we have any data about improvements?

[ADD-SP]

Is this a new feature?

[ProBrian]

It's not a new feature, just a refine, since we use ngx.header[name] to replace _RESPONSE.get_headers()[name] in the get_header implementation, the max headers limitation brought by get_headers() will not exist anymore.

[ADD-SP]

Looks like this extends the capability of this PDK function. Shall we consider this a new feature?

[ProBrian]

I thinks it's not needed to consider this a new feature, because

1. the limitation is due to our internal implementation.
2. the limitation is not documented which means users aren't even aware of this limitation.

that means we have no interface changes and no documentation changes from user's perspective.

[ProBrian]

Do we have any data about improvements?

I did a preliminary test on aws, you can refer to https://konghq.atlassian.net/wiki/spaces/~712020faf780811dc24bb28ad1df7390c03c41/pages/4217667620/A+Journey+to+PDK+Caching#One-more-try-for-the-2nd-half, but that's not a standard test environment. I think we should run a perf test after this PR merged to see.