Hi Ben,
yes, for a stable load without fluctuations you will have a similar throughput with synchronous and asynchronous after a short time.
The asynchronous HTTP client only helps you if you are having other traffic that can be handled without the need for HTTP API calls, and/or if you are having traffic
fluctuations, so you can prevent blocking by buffering requests in memory basically.
Cheers,
Henning
From: Ben Kaufman via sr-users <sr-users@lists.kamailio.org>
Sent: Montag, 26. August 2024 22:30
To: Kamailio (SER) - Users Mailing List <sr-users@lists.kamailio.org>
Cc: Ben Kaufman <bkaufman@bcmone.com>
Subject: [SR-Users] Re: http_async and tm
Does the analogy apply here? Assuming a steady traffic rate and that the http request takes a consistent amount of time, all that's added is PDD as long as latency doesn't increase in the http request with load.
With a blocking HTTP request, then the number of requests that Kamailio can handle becomes limited by the number of children. If it's not blocking, then the limit becomes memory bound, but if the request rate
is static, then the memory limit is also static.
|
From: Alex Balashov via sr-users <sr-users@lists.kamailio.org>
Sent: Saturday, August 24, 2024 7:02 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.
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@lists.kamailio.org> 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("https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2F192.168.86.128%3A8000%2F&data=05%7C02%7Cbkaufman%40bcmone.com%7Cbb95cbcc458744f2b3fa08dcc49aee7a%7Cafc1818e7b6848568913201b9396c4fc%7C1%7C0%7C638601416959677303%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C60000%7C%7C%7C&sdata=022%2FjZEmUuj2RpGEkQiGfLeVHMp30X1jjT3sf3%2FWLRc%3D&reserved=0",
"CRE_RESPONSE");
> }
>
> https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2F192.168.86.128%3A8000%2F&data=05%7C02%7Cbkaufman%40bcmone.com%7Cbb95cbcc458744f2b3fa08dcc49aee7a%7Cafc1818e7b6848568913201b9396c4fc%7C1%7C0%7C638601416959686162%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C60000%7C%7C%7C&sdata=AtjUzO8P4HAO2%2F%2Fh5a5obm9QDAGpNOj7aIx0ofOLe2w%3D&reserved=0 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 Status: 100 Trying |
> 39 1520.094997642 192.168.86.128 → 192.168.86.34 SIP 407 Status: 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 Status: 302 Moved Temporarily |
> 42 1521.591061065 192.168.86.128 → 192.168.86.34 SIP 407 Status: 302 Moved Temporarily |
> 43 1523.591227956 192.168.86.128 → 192.168.86.34 SIP 407 Status: 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@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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fevaristesys.com%2F&data=05%7C02%7Cbkaufman%40bcmone.com%7Cbb95cbcc458744f2b3fa08dcc49aee7a%7Cafc1818e7b6848568913201b9396c4fc%7C1%7C0%7C638601416959692053%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C60000%7C%7C%7C&sdata=eXayCpcLyVM5euSfUlXHfNkLazRMHXa46Iky4t4BlKo%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: