Using async http requests in plugin

Hi,

We are extending the http log plugin, in which we are sending HTTP requests to our logging service multiple times during the flow of the request.

We might have some gap in understanding the way nginx & lua work, but we are worried that making these calls might impact the performance of the requests. We would like to explore the possibility of calling our logging service using async calls - sending the requests without waiting for the response.

Is that something that’s possible to accomplish?

If you use lua-resty-http, which the default HTTP plugin uses and is based on top of the ngx_lua cosocket API, then requests made from your plugin will already be asynchronous and will not impact performance in any significant way.
If you wish to send them concurrently, you can use the ngx.thread API (documentation on the lua-nginx-module README) to schedule them yourself, but this will complicate the logic without drastically improving performance (if you log from the log phase, the response has already been sent to the client anyway, so it matters little if your requests are sequential or concurrent, since all will be asynchronous anyway). Of course, you could benchmark two implementations to find out if your use case suffers or benefit from one implementation or the other. My guess is that the difference will be minimal.

Hi, thanks for the reply!

Our concern is not for the performance of the entire Kong, but the performance of individual requests, we are sending the logs multiple times during the flow of a single request - not only after the response was sent. Meaning that for each log http request lua will wait for the ok response from the log service and then will continue the flow (to the next plugins, upstream, etc…).

What we would like to accomplish is to send the requests to the logs service and NOT wait for the http response, and continue the flow.

You could still use the ngx.thread api as @thibaultcha suggested, in that case the whole log request is async. Alternatively a timer could be used. Either way you will probably consume more resources. E.g. when you make 3 log requests during a single request-cycle, it means having 5 sockets (in, out, 3x log), additionally 3 extra light-threads/timers. (This assumes the worst-case, that the full log-request hasn’t been completed, when the next starts)