In my case, problem is 100% in the REST API, trying to ‘fix’ it in kamailio was just an option that i was exploring or more like ‘am i doing something wrong?’
I gave up now on the kamailio side (only added more cpu’s and children to absorb he shockwave) and working on the API to start caching things in a redis and getting the ‘external’ data in a different thread to avoid the processing delay. I believe this will be the bigger gain. > On 27 Aug 2024, at 8:57 AM, Alex Balashov via sr-users > <[email protected]> wrote: > > >> On Aug 27, 2024, at 4:17 AM, Henning Westerholt via sr-users >> <[email protected]> wrote: >> >> 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. > > Indeed. It's also worth reiterating that the meaning of "asynchronous" is > somewhat environmentally and implementationally specific. > > As the term has entered general use with the popularity of single-threaded / > single event loop multiplexing systems, such as Node and JavaScript, it has > come to refer to a programming and processing pattern in which the waiting > and detection of I/O is delegated to the OS kernel network stack. The OS > takes care of this juggling and calls event hooks or callbacks in your > program when there is I/O to consume, or sets some flag or condition to > indicate this so that you can read the I/O from some OS buffer at your > convenience. In this way, your program is able to proceed executing other > kinds of things while the OS is taking care of waiting on I/O. Provided that > the workload consists of waiting on I/O and also other things, this is to the > general benefit of "other things", not the I/O. > > In Kamailio, 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, also part of a relatively small, fixed-size pool. Within > those ancillary worker processes, the execution is as linear, synchronous and > blocking as it would be in the main worker processes. This does not cause the > processing to enter some generally more asynchronous mode in any other > respect, and in that sense, is quite different to what most people have in > mind when they think of asynchronous processing in the context of > general-purpose programming runtimes. > > The only real footnote to this is about situations in which the resumption of > the transaction in the async workers is mediated by external events, e.g. a > POST-back into Kamailio's `xhttp` server. While this does not change the > nature of the subsequent synchronous execution of the route logic, it does > mean that neither a core CIP worker nor an async worker is tied up while some > kind of external processing is playing out. > > -- Alex > > -- > 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 [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:
