Hello, just wondering what would be the best approach to use http_async_client on a stateless redirect server, if that is even possible. Any examples to share?
Also, as a side note, documentation/wiki Kamailio Modules <https://kamailio.org/docs/modules/5.8.x/#H> states that HTTP_CLIENT is a "Sync and async HTTP client using CURL library" but there are no examples on how to use async HTTP with this module.... Atenciosamente / Kind Regards / Cordialement / Un saludo, *Sérgio Charrua* On Fri, Dec 20, 2024 at 10:19 AM Stefan via sr-users < [email protected]> wrote: > > Hi, Tried to comment yesterday but it didn't go through. > > <snip> > I would suggest use some message bus technology, work with services > accessed over that bus and data that live in RAM. Choose your favorite > programming language and build. I typically work with roundtrip times > of microseconds. Then you can do pretty much what you like, no > problems. > > //s > </snip> > > Now that I see the services accessed, ST/SH, is "http across town", > nothing changes, then whatever http is to be processed should be done at/as > a service. > Accessed using your favorite message bus tech. from Kamailio. > Keeping the kamailio processing asynch and using an edge triggered message > bus. > > Regards, > Stefan > > > > > tor 2024-12-19 klockan 20:34 -0500 skrev Alexis Fidalgo via sr-users: > > The mentioned ‘aws hosted webservice’ on my email is a stir shaken + call > fraud scoring + ecnam service, no possible cache there. > > Actually the diameter section is not cacheable either (leads to false > positives) I just tested and mentioned it with the intention to graphic > the concept of ‘delete the wait’ (if possible) > > Sometimes caching is not possible at all. And the price (as we pay) is to > assign resources and watch it being occupied waiting. Trust me, 9000 caps > made me try a lot of paths > > > Enviado desde dispositivo móvil > > El 19 dic 2024, a la(s) 7:12 p. m., Sergio Charrua <[email protected]> > escribió: > > > I understand the idea behind using cache facilities, however in this case, > being a ST/SH attestation service, all calls need to be attested and the > probability that multiple calls having src and dst numbers identical is, > IMHO, very reduced. > So I don't see how a caching system could be used here, hence why HTTP is > "a necessary evil".... unless i'm missing something here.... > > Atenciosamente / Kind Regards / Cordialement / Un saludo, > > > *Sérgio Charrua* > > On Thu, Dec 19, 2024 at 11:19 PM Alexis Fidalgo via sr-users < > [email protected]> wrote: > > To add some information if useful. In our case there are 2 main “actions” > performed as processing when http service is called that takes a lot of > time (there are more but are negligible against these 2) > > 1. A query to an Diameter DRA (which for external reasons or customer > reasons) takes an average of 150ms (and in some other cities of the deploys > can take more because of the delay in the links) > 2. A query to a rest webservice that is in AWS, not that bad as point 1 > but still bad (~70ms) > > So, in the best of scenarios, we have ~225ms, maybe if the DRA load > balances to another HSS we get ~180ms total call processing. > > That is bad, really bad. > > To probe the idea and before any major changes in any part, I started to > keep DRA responses in a redis (we use dragonfly), it’s not consistent in > terms of our call processing flow but my idea was to “remove” the delay of > the diameter query (I run the query, keep the result in redis, when a new > request arrives for the same value I use the cached value and send a new > DRA query in other thread to avoid lock the current one and update the > redis). > > With this, we removed the DRA query wait, so 220ms became 70/72ms. > > Instantly all cpu usage, all retransmissions, everything disappeared, cpu, > mem went down drastically, etc etc. > > That’s why I mentioned ’wait time is the enemy’, http is not (maybe is not > your best friend but not the enemy). If it works, there’s an analogy, you > can try to improve aerodynamics, engine and whatever in a F1 car, but if > the driver is heavy … > > Hope it helps > > > > On Dec 19, 2024, at 5:18 PM, Alex Balashov via sr-users < > [email protected]> wrote: > > > > > >> On Dec 19, 2024, at 1:06 pm, Calvin E. via sr-users < > [email protected]> wrote: > >> > >> Consider scaling out instead of scaling up. Now that you know the > >> apparent limit of a single node for your use case, put it behind a > >> Kamailio dispatcher. > > > > On the other hand, you might consider scaling up first, since HTTP > performs so badly that there is lots of improvement to be squeezed out of > optimising that even a little. > > > > You might think of scaling out as a form of premature optimisation. :-) > > > > -- Alex > > > > -- > > 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! > > __________________________________________________________ > 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! > > > __________________________________________________________ > 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!
