significantly impacting performance-JIT NYI

[fairyqb]

Is there an existing issue for this?

• 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/

[bungle]

@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.

[fairyqb]

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]

Has anyone encountered this issue?

[bungle]

@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

[fairyqb]

Good idea.
Scenario: Add the global request-transformer plugin, and there are some headers that need to be removed during the plugin.

[chronolaw]

@bungle do we have PR to improve this perf issue?

[bungle]

@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.

[chronolaw]

KAG-7574 to track it.

[chronolaw]

@fairyqb could you open a PR to fix it? I think that currently we have not too much bandwidth for it. thanks.

[fairyqb]

sorry, our team is fully occupied with projects. @chronolaw

[chronolaw]

track by https://konghq.atlassian.net/browse/KAG-7574.