help request: Could we set a timeout skip strateges for per plugin processing a request?

[leohowell]

Description

Can we set a per-request timeout for the plugin?

When the plugin execution times out, we skip this plugin and execute the next one.

How to achieve it in a lua plugin or in apisix control code?

Environment

• APISIX version (run apisix version): 2.14.1
• Operating system (run uname -a):
• OpenResty / Nginx version (run openresty -V or nginx -V):
• etcd version, if relevant (run curl http://127.0.0.1:9090/v1/server_info):
• APISIX Dashboard version, if relevant:
• Plugin runner version, for issues related to plugin runners:
• LuaRocks version, for installation issues (run luarocks --version):

[tokers]

Technically, this feature gets involved in the preemptive schedule of Lua threads (you plugin codes might always run on CPU).

I'm interested into the scenario that you want to solve. Could you just provide it?

[leohowell]

That's it! It's really CPU-bound. I'm building a WAF plugin, based on Lua code and a Rust dylib.

It has hundreds of rules, most of them are regular expressions. I verified with the flame graph, most of the CPU is consumed on regular matching(DFA). The time for regular matching increases linearly with the size of the request body.

So the question is I want my plugin to have a response time guarantee, not affected by the size of the request body.

[tokers]

That's it! It's really CPU-bound. I'm building a WAF plugin, based on Lua code and a Rust dylib.

It has hundreds of rules, most of them are regular expressions. I verified with the flame graph, most of the CPU is consumed on regular matching(DFA). The time for regular matching increases linearly with the size of the request body.

So the question is I want my plugin to have a response time guarantee, not affected by the size of the request body.

Another way of thinking is avoiding the execution of WAF blocks other requests' running. So why not add some ngx.sleep(0) hooks in your codes so that other requests can also get the chance to run during the WAF execution.

[tzssangglass]

Another way of thinking is avoiding the execution of WAF blocks other requests' running. So why not add some ngx.sleep(0) hooks in your codes so that other requests can also get the chance to run during the WAF execution.

IMO, ngx.sleep(0) does not solve the problem, I did not verify that could use ngx.sleep(0) during regular matching. (I remember that it is not possible)

Perhaps we could use this: https://github.com/openresty/lua-nginx-module#ngxrun_worker_thread, let a dedicated worker handle it.

[github-actions[bot]]

This issue has been marked as stale due to 350 days of inactivity. It will be closed in 2 weeks if no further activity occurs. If this issue is still relevant, please simply write any comment. Even if closed, you can still revive the issue at any time or discuss it on the [email protected] list. Thank you for your contributions.

[github-actions[bot]]

This issue has been closed due to lack of activity. If you think that is incorrect, or the issue requires additional review, you can revive the issue at any time.