Semantics aside, the issue from the original post isn't so much that "the http request blocks processing the SIP message", but that "the http request blocks processing the SIP message for about a second, during which time the process cannot do anything else".  If the original poster's web server responded in less than 5ms, we wouldn't be having this conversation.  

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.



Kaufman
Senior Voice Engineer



E: bkaufman@bcmone.com


 

SIP.US Client Support: 800.566.9810  |  SIPTRUNK Client Support: 800.250.6510  |  Flowroute Client Support: 855.356.9768
img
img
img
 

From: Alex Balashov via sr-users <sr-users@lists.kamailio.org>
Sent: Thursday, August 29, 2024 4:30 PM
To: Kamailio (SER) - Users Mailing List <sr-users@lists.kamailio.org>
Cc: Alex Balashov <abalashov@evaristesys.com>
Subject: [SR-Users] Re: http_async and tm
 
CAUTION: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.


> On Aug 29, 2024, at 5:05 PM, Ben Kaufman <bkaufman@bcmone.com> wrote:
>
>     • so it looks like success.
>
> How is it not success?  It is not just "not dropping messages".  All messages are responded to in only slightly longer than the 1 second delay provided by the web server. How is handling 300 request per second rather than 2 (the number of children) not an improvement in throughput?

"Looks like success [with the tacit insinuation that it's actually not]" was probably uncharitable. You're right that

However, it's not an increase in _throughput_. It's a work around Kamailio's concurrency architecture vis-a-vis HTTP. You've just created an elastic buffer for slow HTTP requests. There is, essentially, process A (SIP worker) and process B (async worker), and they both process the request the same way.

Moving the work to process B is beneficial because it's not exposed to incoming SIP packets, while process A is. Instead of waiting on HTTP requests in processes of type A, you're waiting on them in processes of type B. You're still blocking a process and waiting. Vitally, the throughput is still bounded by process B and by available memory, and, more to the point, the considerations, and limitations, around increasing the number of processes, of either the A or B type, are the same.

The picture I painted was:

   "asynchronous processing just means liberating the transaction
    from the main worker processes, which are part of a relatively
    small fixed-size pool, by suspending it and shipping it to
    another set of ancillary worker processes"

Your critique of this was, as I understood it:

   "this does not simply 'hand off the transaction' to another
    pool of workers which then accumulate load."

My only aim here is to say that this is, in fact, an accurate characterisation of what is happening. You are handing off the transaction to another pool of workers. I also meant to convey that Kamailio's async model is more coarse than that of async I/O in other execution environments.

-- Alex

--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fevaristesys.com%2F&data=05%7C02%7Cbkaufman%40bcmone.com%7Ca2bdc9e44c6e46c296a008dcc8730ddf%7Cafc1818e7b6848568913201b9396c4fc%7C1%7C0%7C638605643717791558%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=GWxDbgBAWAGGA5tNycV%2Flieul9O55ejRIi%2FWWE83eMY%3D&reserved=0
Tel: +1-706-510-6800

__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-leave@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe: