You're still conflating `http_async_client` with async.  I'm not arguing the former as an absolute panacea, but the behavior you describe is consistent with how async works, not http_async_client. 

Async will move the message handling to another process immediately.  If it sends an http request using http_client, then that new process will be blocked.  This is very useful when a small percentage of requests will require doing something that takes a long time.

Unless I'm wrong (and testing shows this to be the case), http_async_client will send an http request, store the request to memory, and release the process. As long as there is no http reply, there is no blocked process.  Only when a reply is received is the SIP request processing resumed.

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, December 19, 2024 11:24 AM
To: sr-users@lists.kamailio.org <sr-users@lists.kamailio.org>
Cc: Alex Balashov <abalashov@evaristesys.com>
Subject: [SR-Users] Re: Kamailio not receiving packets on high CPS
 
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 Dec 19, 2024, at 12:04 pm, Ben Kaufman <bkaufman@bcmone.com> wrote:
>
> In this case, the "moving food around on the plate" is moving the process blocking of the http request (which is just wait time) to increased memory usage by storing the request in memory.  The number of message able to be handled over a sustained period increases (full stop).   Of course there' still an upper bound based on memory and that should be considered.  It's not a "limitless fix", but buy creating a queue for the requests in memory the upper bound gets increased.

I think we've had this polemic before. Yes, the upper bound is increased in some non-zero amount, but the returns to actual call throughput per se can be marginal vs just increasing core children drastically, just depending on the exact parameters of the situation. Increasing core children invites contention problems beyond a certain point, and the same is true of background async workers.

There are better and worse ways of dealing with the latter; individuated mqueues are a good solution. core_hash() over Call-ID helps with pseudo-random distribution over independent pipelines to background workers, versus having them share queue lock.

The best use-case for background async workers is for stuff that isn't in the critical path of call processing and is highly deferrable, such as call accounting. Otherwise, the results aren't that great in the end, if throughput is your top concern. Alexis Fidalgo said it:

"[...] still 'hiding' the problem. Improves? Yes. Fixes? Not at all."

-- 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%7Ca10568d324034c0126aa08dd20536721%7Cafc1818e7b6848568913201b9396c4fc%7C1%7C0%7C638702264774410201%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=vdcYKyCOU74%2F5%2FI%2B5ZpcMqzTpJdoKrxjWLuLZIgu5dA%3D&reserved=0
Tel: +1-706-510-6800

__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org
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!