The existence and popularity of HTTP client modules (of both flavours) suggests that this is a contentious topic, but HTTP queries can serve lots of purposes.
Based on my experience, my position within that discourse is to not do HTTP from Kamailio at all, at least not in high-volume environments where the HTTP query is also part of the call processing. That is the most honest and best advice I can give to anyone concerned specifically with maximising throughput. Kamailio is good at SIP, though. You should use that. -- Alex > On Dec 19, 2024, at 12:24 pm, Alex Balashov <[email protected]> wrote: > > >> On Dec 19, 2024, at 12:04 pm, Ben Kaufman <[email protected]> wrote: >> >> In this case, the "moving food around on the plate" is moving the process >> blocking of the http request (which is just wait time) to increased memory >> usage by storing the request in memory. The number of message able to be >> handled over a sustained period increases (full stop). Of course there' >> still an upper bound based on memory and that should be considered. It's >> not a "limitless fix", but buy creating a queue for the requests in memory >> the upper bound gets increased. > > I think we've had this polemic before. Yes, the upper bound is increased in > some non-zero amount, but the returns to actual call throughput per se can be > marginal vs just increasing core children drastically, just depending on the > exact parameters of the situation. Increasing core children invites > contention problems beyond a certain point, and the same is true of > background async workers. > > There are better and worse ways of dealing with the latter; individuated > mqueues are a good solution. core_hash() over Call-ID helps with > pseudo-random distribution over independent pipelines to background workers, > versus having them share queue lock. > > The best use-case for background async workers is for stuff that isn't in the > critical path of call processing and is highly deferrable, such as call > accounting. Otherwise, the results aren't that great in the end, if > throughput is your top concern. Alexis Fidalgo said it: > > "[...] still 'hiding' the problem. Improves? Yes. Fixes? Not at all." > > -- Alex > > -- > Alex Balashov > Principal Consultant > Evariste Systems LLC > Web: https://evaristesys.com > Tel: +1-706-510-6800 > -- Alex Balashov Principal Consultant Evariste Systems LLC Web: 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!
