On Dec 23, 2024, at 5:12 pm, Ben Kaufman
<bkaufman(a)bcmone.com> wrote:
As a curiosity, if one were to create an EVAPI client to handle these requests,
wouldn't the transaction still need to be stored in shared memory with somewhat
similar memory usage?
Yes.
I'm not quite clear why you keep stating that
it's not going to be free. I never claimed it to be. In fact, I've consistently
stated that the cost is in shared memory, and I don't see any possible way in which
the requests could be processed that is not in shared memory somewhere UNLESS the response
time can be addressed.
There is every other cost associated with processing the request, too, although I'll
be the first to acknowledge that kernel-side socket polling is massively more efficient,
for all sorts of reasons: reduced context switches, optimal data structures for chaining
large numbers of file descriptors, etc. But actually reading the data off the socket, and
processing it, still happens in the worker.
I think we're talking about two different things:
- You're talking about what's fastest given Kamailio's process constraints
(and I am happy to agree with you, and I am also happy to concede that developing a
methodology for a rigourous quantitative comparison of the total-system energetics of both
approaches would be challenging);
- I'm talking about async not really getting around the fact that HTTP is slow and
cumbersome, and so that truly throughput-maximising approaches would get Kamailio out of
that business altogether.
Kamailio is a middleware, a kind of Node, and it's architected as such. It's best
at facilitating interchange of SIP messages going to and from other places. There is a
begrudging need to interact with other services using other protocols, as well, but it
should be kept to a minimum and the footprint should be as small as possible for highest
performance. HTTP is more like hammering in a nail with a microscope.
-- Alex
--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web:
https://evaristesys.com
Tel: +1-706-510-6800