27 Aug
2024
27 Aug
'24
3:39 p.m.
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
<sr-users(a)lists.kamailio.org> wrote:
On Aug 27, 2024, at 4:17 AM, Henning Westerholt
via sr-users <sr-users(a)lists.kamailio.org> 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 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: