Kong
significantly impacting performance-JIT NYI
Is there an existing issue for this?
- [x] I have searched the existing issues
Kong version ($ kong version)
all
Current Behavior
jit.v log:
[TRACE --- access.lua:163(@/usr/local/kong-3.9.1/plugins/request-transformer/access.lua) -- NYI: bytecode 72 at access.lua:227(@/usr/local/kong-3.9.1/plugins/request-transformer/access.lua)]
There is a significant decrease in QPS
Steps To Reproduce
Add code to init.lua:
local v = require "jit.v" v.on("/tmp/jit.log")
wrk -t100 -c100 -d10m http://www.test.link/user/
@fairyqb how big is the drop. Do you have something in that table? From looks of it it seems to be cresting empty tables and then looping. Some of this can really be optimized. Thanks.
There are more than 56 key values in the table, which is greater than the hotloop parameter, What optimization suggestions are there? Using while next is not ideal compared to pairs. Thank you.
@fairyqb can you post the plugin configuration and example request. Yes, pairs if NYI. I am wondering whether making the headers_to_remove an array instead of hash could fix it (and then just using ipairs or for loop). Seems rather straight forward to do it as the header_to_remove is only used in couple of places:
...
headers_to_remove[name] = true
...
headers_to_remove[old_name] = true
...
for name, _ in pairs(headers_to_remove) do
clear_header(name)
end
e.g. something like:
local n = 0
...
n = n + 1
headers_to_remove[n] = name
...
n = n + 1
headers_to_remove[n] = old_name
...
if n > 0 then
for i = 1, n do
clear_header(headers_to_remove[i])
end
end
Good idea. Scenario: Add the global request-transformer plugin, and there are some headers that need to be removed during the plugin.
@bungle do we have PR to improve this perf issue?
@chronolaw,
I don't think so. I was thinking about fixing this, but currently I am busy with other tasks. Anyone could take this. There are other things we can optimize in this plugin but the above may be a good initial fix. Provided that it actually helps.
@fairyqb could you open a PR to fix it? I think that currently we have not too much bandwidth for it. thanks.