On Dec 23, 2024, at 5:12 pm, Ben Kaufman bkaufman@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