On Dec 23, 2024, at 3:14 pm, Ben Kaufman
<bkaufman(a)bcmone.com> wrote:
The difference in performance is substantial.
If you confine the scope of your evaluation to Kamailio itself, then of course it's
substantial; you've deputised the event mux/polling workload into kernel space. While
that makes it invisible, it doesn't obviate the clock cycles.
This is like saying that Node can handle a tremendous amount of requests with a single
process. I suppose it can, but only because it's able to farm out the work of
monitoring sockets for data to the OS, and erase it from the ledger, if you like, of
userspace costs. They still go somewhere, and that somewhere is constrained by available
resources and dimensioning.
Assuming you've used this repo and assets to make your case:
https://github.com/whosgonna/kamailio_http_async
this is not a fair or reasonable comparison. In one case, you're using an external
polling loop, and in the other, you're blocking your worker processes by definition. I
doubt you could get 3 CPS through that config if the async shvar is set to 0.
Furthermore, the idea of an HTTP service that responds like a metronome in 1 sec, over
local sockets and without any of the overhead of connection setup over a real-world
network, is so contrived as to be tautological. You've neutered the synchronous
approach to the maximum possible extent, while testing the asynchronous one in highly
idealised conditions. In fact, tried your repo, followed your instructions on a hex-core
server with 16 GB of RAM (2 GB of SHM allocated to Kamailio) and was able to get about
1600 CPS -- more than twice the OP's ask -- before seeing any retransmissions.
It's so contrived as to be tautological, as if to say that being rich, young and
healthy is better than being old, ill and poor. I cannot agree more.
If you empower the synchronous http_client approach with a comparable degree of
parallelism, i.e. a large pool of worker processes with minimum package memory, you'll
get comparable throughput. I agree that there are memory limits around that in
Kamailio's concurrency model, and that was never in dispute. But you're going to
pay it somewhere either way:

Are we talking about performance, or are we talking about which HTTP client module
delivers more throughput within Kamailio's architectural constraints? If the latter,
this was never in dispute in my mind.
-- Alex
--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web:
https://evaristesys.com
Tel: +1-706-510-6800