[SR-Users] Re: http_async and tm

On Aug 25, 2024, at 3:11 AM, Henning Westerholt <hw(a)gilawa.com>

Hello Alex, are you saying that using Kamailio with HTTP is not performant at all? This

Regarding children to CPU core ratios, the default configuration is already

Cheers, Henning -- Henning Westerholt – https://skalatan.de/blog/ Kamailio services – https://gilawa.com > -----Original Message----- > From: Alex Balashov via sr-users <sr-users(a)lists.kamailio.org> > Sent: Sonntag, 25. August 2024 06:18 > To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org> > Cc: Alex Balashov <abalashov(a)evaristesys.com> > Subject: [SR-Users] Re: http_async and tm > > A few hundred CPS per node is impressive, but especially so when > anything with HTTP is involved! Kamailio has HTTP client modules, but > there's no pretending that being an HTTP client is natural or > particularly performant for Kamailio. > > Since most--not all, but most--of the workload is I/O wait, you could > get away with just adding more children. The general principle that > children should not exceed CPUs, because they'd just fight for CPU, > applies when the workload is CPU-bound, or computational in nature. > However, if most of the time is spent waiting on something to come > across a socket, e.g. from a database or an HTTP server, you can overbook

> > You still don't want too many child processes, and I would be > hard-pressed to say exactly how many is too many, but 2:1 or 3:1 should

> > -- Alex > >>> On Aug 24, 2024, at 10:35 PM, Alexis Fidalgo <alzrck(a)gmail.com>

>> >> it is. im dealing with this issue since a few weeks, i can push and >> add more > cpu’s and more children and play with queues, timeouts, etc etc. but > i know, im pretty sure that there’s a limit i can't surpass. >> >> at this point im struggling on how to modify the http part (the api >> server) it > would be great (and easy for me) if the execution pipelines can at > least have some part where in can execute in parallel, but … a > pipeline, why to execute following steps if not needed vs ‘execute > and discard’ (and worst, some consumed webservices in the pipeline are

>> >> im happy, more that that, a docker swarm with 4 nodes with >> 10cpu/children each are handling ~1300 call attempls >> (invite,100,302,ack) per second, thats more than ok (and cpu/mem are >> low, really low, problem is the wait, no the power), but we need >> more (ill move to more cores/childrens and appeal to brute force by >> now to gain some time) >> >> still seeing there’s no point to start using TM for a 100% stateless >> flow >> >> >>> On 24 Aug 2024, at 9:02 PM, Alex Balashov via sr-users <sr- > users(a)lists.kamailio.org&gt; wrote: >>> >>> Not overtly related to your most immediate question, but: >>> >>> 1) "we're hitting a limit where all children become busy waiting >>> for the API > to answer." >>> >>> 2) "So i decided to move to http_async_client" >>> >>> I'm not sure this is really going to solve your problem. You've hit > fundamental, thermodynamic kind of limits here. Using async here just > squeezes the balloon in one place and causes it to inflate in another. >>> >>> It would be different if some of your workload were HTTP-dependent >>> and > other parts of the workload were not. Doing the HTTP queries would > free up the core SIP workers to process other kinds of requests. That > doesn't sound like it's the case, so all you're really liberating is > reply processing, which, if this is a redirect server, is nonexistent anyway. >>> >>> This matter might occasion some deeper reflection. >>> >>> -- Alex >>> >>>> On Aug 24, 2024, at 6:48 PM, alexis via sr-users <sr- > users(a)lists.kamailio.org&gt; wrote: >>>> >>>> Hello all, context first, we have an REST API that performs >>>> queries to > external devices in the network (diameter to DRA's, REST to different > servers) and based on n conditions returns the content for a Contact > header to be used in a SIP 302. >>>> >>>> Now we're consuming this API with http_client (synchronously) and >>>> as > there's no way to speed up the API (pipeline executions, delays on > external api's etc etc) we're hitting a limit where all children > become busy waiting for the API to answer. >>>> >>>> So i decided to move to http_async_client and started working on >>>> it on the > lab with this first and base concept to test. >>>> >>>> request_route { >>>> >>>> >>>> #for testing purposes only >>>> if(is_method("ACK")){ >>>> exit; >>>> } >>>> $http_req(all) = $null; >>>> $http_req(suspend) = 1; >>>> $http_req(timeout) = 500; >>>> $http_req(method) = "POST"; >>>> $http_req(hdr) = "Content-Type: application/json"; >>>> jansson_set("string", "event", "sip-routing", "$var(cre_query)"); >>>> xlog("L_INFO","API ASYNC ROUTING REQUEST: $var(cre_query)\n"); >>>> $http_req(body) = $var(cre_query); t_newtran(); >>>> http_async_query("http://192.168.86.128:8000/", "CRE_RESPONSE");

>>>> >>>> http://192.168.86.128:8000/ receives the POST, randomly creates a >>>> delay between 0.5 and 1 second and responds (simulating the real >>>> api with an excess delay to probe the concept) >>>> >>>> Then >>>> >>>> route[CRE_RESPONSE] { >>>> if ($http_ok && $http_rs == 200) { >>>> xlog("L_INFO","CRE RESPONSE: $http_rb\n"); # for testing >>>> purpose, Contact content will be replaced from the received api >>>> response >>>> append_to_reply("Contact: <sip:1234@google.com>\r\n"); >>>> send_reply(302,"Moved Temporarily"); exit; } send_reply(500, >>>> "Internal error"); exit; } >>>> >>>> INVITE is received and processed, API is called, after API >>>> response, 302 is > replied and then an ACK (ignored by now). >>>> >>>> Situation is that the 302 retransmitted >>>> >>>> 37 1519.846253067 192.168.86.34 → 192.168.86.128 SIP/SDP 585 >>>> Request: INVITE sip:service@192.168.86.128:5060 | >>>> 38 1519.848100380 192.168.86.128 → 192.168.86.34 SIP 318

>>>> 100 Trying | >>>> 39 1520.094997642 192.168.86.128 → 192.168.86.34 SIP 407

>>>> 302 Moved Temporarily | >>>> 40 1520.102323728 192.168.86.34 → 192.168.86.128 SIP 453 > Request: >>>> ACK sip:service@192.168.86.128:5060 | >>>> 41 1520.591300933 192.168.86.128 → 192.168.86.34 SIP 407

>>>> 302 Moved Temporarily | >>>> 42 1521.591061065 192.168.86.128 → 192.168.86.34 SIP 407

>>>> 302 Moved Temporarily | >>>> 43 1523.591227956 192.168.86.128 → 192.168.86.34 SIP 407

>>>> 302 Moved Temporarily | >>>> >>>> >>>> 18(24) DEBUG: tm [t_reply.c:1703]: t_retransmit_reply(): reply >>>> retransmitted. buf=0x7f6d79745dc0: SIP/2.0 3..., >>>> shmem=0x7f6d75187fd8: SIP/2.0 3 >>>> 18(24) DEBUG: tm [t_reply.c:1703]: t_retransmit_reply(): reply >>>> retransmitted. buf=0x7f6d79745dc0: SIP/2.0 3..., >>>> shmem=0x7f6d75187fd8: SIP/2.0 3 >>>> 18(24) DEBUG: tm [t_reply.c:1703]: t_retransmit_reply(): reply >>>> retransmitted. buf=0x7f6d79745dc0: SIP/2.0 3..., >>>> shmem=0x7f6d75187fd8: SIP/2.0 3 >>>> 18(24) DEBUG: tm [timer.c:634]: wait_handler(): finished >>>> transaction: 0x7f6d75184cc8 (p:0x7f6d74f600c8/n:0x7f6d74f600c8) >>>> 18(24) DEBUG: tm [h_table.c:132]: free_cell_helper(): freeing >>>> transaction 0x7f6d75184cc8 from timer.c:643 >>>> >>>> Any help to avoid the retransmission and make the transaction just >>>> finish > right after the 302 will be appreciated. >>>> >>>> regards >>>> >>>> >>>> >>>> >>>> >>>> __________________________________________________________ >>>> Kamailio - Users Mailing List - Non Commercial Discussions To >>>> unsubscribe send an email to sr-users-leave(a)lists.kamailio.org >>>> Important: keep the mailing list in the recipients, do not reply >>>> only to the > sender! >>>> Edit mailing list options or unsubscribe: >>> >>> -- >>> Alex Balashov >>> Principal Consultant >>> Evariste Systems LLC >>> Web: https://evaristesys.com >>> Tel: +1-706-510-6800 >>> >>> __________________________________________________________ >>> Kamailio - Users Mailing List - Non Commercial Discussions To >>> unsubscribe send an email to sr-users-leave(a)lists.kamailio.org >>> Important: keep the mailing list in the recipients, do not reply >>> only to the > sender! >>> Edit mailing list options or unsubscribe: >> > > -- > Alex Balashov > Principal Consultant > Evariste Systems LLC > Web: https://evaristesys.com > Tel: +1-706-510-6800 > > __________________________________________________________ > Kamailio - Users Mailing List - Non Commercial Discussions To > unsubscribe send an email to sr-users-leave(a)lists.kamailio.org > Important: keep the mailing list in the recipients, do not reply only > to the sender! > Edit mailing list options or unsubscribe: