* 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.
I think we can conclude on that point, as I agree in the general sense. I'm not trying to push Kamailio as a first tier HTTP relay. After all, Kamailio can also handle http requests, and therefore it could be used as a generic http proxy, but I think we can all agree on what a terrible idea that would be. It is my opinion that if planned well, it should be reasonable to create a purpose-driven service where Kamailio makes requests to http servers. But that's just my opinion. Kaufman Senior Voice Engineer E: [email protected] SIP.US Client Support: 800.566.9810 | SIPTRUNK Client Support: 800.250.6510 | Flowroute Client Support: 855.356.9768 [img]<https://www.sip.us/> [img]<https://www.siptrunk.com/> [img]<https://www.flowroute.com/> ________________________________ From: Alex Balashov via sr-users <[email protected]> Sent: Monday, December 23, 2024 4:23 PM To: [email protected] <[email protected]> Cc: Alex Balashov <[email protected]> Subject: [SR-Users] Re: Kamailio not receiving packets on high CPS CAUTION: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. > On Dec 23, 2024, at 5:12 pm, Ben Kaufman <[email protected]> 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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fevaristesys.com%2F&data=05%7C02%7Cbkaufman%40bcmone.com%7C32032250361844cca89308dd23a1330a%7Cafc1818e7b6848568913201b9396c4fc%7C1%7C0%7C638705897456751177%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=XIEl%2B8cuOxaJt4LvLoApVOIzwmqaHZ9HRbpifWIZiyg%3D&reserved=0<https://evaristesys.com/> Tel: +1-706-510-6800 __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions -- [email protected] To unsubscribe send an email to [email protected] Important: keep the mailing list in the recipients, do not reply only to the sender!
__________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions -- [email protected] To unsubscribe send an email to [email protected] Important: keep the mailing list in the recipients, do not reply only to the sender!
