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: [email protected] SIP.US Client Support: 800.566.9810 | SIPTRUNK Client Support: 800.250.6510 | Flowroute Client Support: 855.356.9768 [img]<https://www.sip.us/> [img]<https://www.siptrunk.com/> [img]<https://www.flowroute.com/> ________________________________ From: Alex Balashov via sr-users <[email protected]> Sent: Thursday, August 29, 2024 4:30 PM To: Kamailio (SER) - Users Mailing List <[email protected]> Cc: Alex Balashov <[email protected]> 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 <[email protected]> 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<https://evaristesys.com/> Tel: +1-706-510-6800 __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to [email protected] Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
__________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to [email protected] Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
