30 Aug
2024
30 Aug
'24
2:53 p.m.
On Aug 29, 2024, at 6:35 PM, Ben Kaufman
<bkaufman(a)bcmone.com> wrote:
So, using kamailio's ASYNC module, the pattern would be to call async_task_route() in
listener process A. This passes the transaction to async_worker process A. Then, in the
async_worker process, the http request is made and that async worker process is blocked
until the web server responds. And yes, if that's what is happening it is just moving
the wait time from one process to another.
With the http async client, however, my understanding is that the request is sent from
listener process A, and then the transaction is suspened. The http async worker process,
which not the same as async workers, is running an event loop (libevent is a requirement
for http async client). When a http reply is received, the http async worker will resume
the transaction that sent the request.
The difference is that with the http async client, waiting for the http reply doesn't
block anything. Supposing we have a single listener process and a single http async
worker process. In very quick succession, 5 SIP requests are received, all requiring an
http request. If the 5th http request is the first to receive an http response, then that
response will be handled immediately - it's not blocked waiting for the prior 4 http
replies.
I understand your argument, as I did before. There is a nonblocking socket event mux, in a
dedicated process outside of the normal process pools, which is running an event loop on
behalf of those normal processes and activating async workers with a resumed transaction
when an HTTP reply is received. While that waiting is happening, the async workers are not
themselves blocked.
However, in this setup, the async workers only do one kind of thing -- postprocess the
HTTP response. That's all they do. So, there's nothing they're freed up to do
by not waiting on HTTP queries, and, conversely, there's nothing to be gained from
adding more of them in this paradigm that wouldn't also be gained by adding more of
them and having them each do a blocking HTTP query, as in the first paradigm you discussed
above.
This whole polemic is rooted in the fact that issuing redirects based on HTTP responses is
all that this proxy does. If it did anything else, these would all be fair points.
-- Alex
--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: https://evaristesys.com
Tel: +1-706-510-6800