+1 on request :)
> On 23 Dec 2024, at 9:01 AM, Sergio Charrua via sr-users > <[email protected]> wrote: > > Any docs/articles you could share? besides Kamailio docs.... > > Atenciosamente / Kind Regards / Cordialement / Un saludo, > > Sérgio Charrua > > On Mon, Dec 23, 2024 at 12:58 PM Stefan via sr-users > <[email protected] <mailto:[email protected]>> wrote: >> >> Just a short followup. >> >> It looks as modules evapi and asynch could be used to build access to a >> service using a messagebus. >> Will probably try it. Looks interesting enough. >> >> //s >> >> >> lör 2024-12-21 klockan 19:11 +0100 skrev Stefan via sr-users: >>> >>> Never had to use it. If you work with roundtrip times in microseconds, it >>> becomes irrelevant. >>> Have been replacing Req./Rep. situations with events, dataflows and >>> triggers effectively removing the associated latencies. >>> >>> Implementing ST/SH, or similar, services is interesting though. I can see >>> the value, but implemented as suggested previously. >>> There are probably others on the list that can suggest how processing >>> suspend/resume can be done in a good way. >>> It's suspend/resume you want. http_whatever is probably not. >>> >>> Regards, >>> Stefan >>> >>> lör 2024-12-21 klockan 11:40 +0100 skrev Sergio Charrua via sr-users: >>>> 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] <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[email protected]>> >>>>>>>> > wrote: >>>>>>>> > >>>>>>>> > >>>>>>>> >> On Dec 19, 2024, at 1:06 pm, Calvin E. via sr-users >>>>>>>> >> <[email protected] <mailto:[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 <https://evaristesys.com/> >>>>>>>> > Tel: +1-706-510-6800 >>>>>>>> > >>>>>>>> > __________________________________________________________ >>>>>>>> > Kamailio - Users Mailing List - Non Commercial Discussions -- >>>>>>>> > [email protected] <mailto:[email protected]> >>>>>>>> > To unsubscribe send an email to [email protected] >>>>>>>> > <mailto:[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] <mailto:[email protected]> >>>>>>>> To unsubscribe send an email to [email protected] >>>>>>>> <mailto:[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] <mailto:[email protected]> >>>>>> To unsubscribe send an email to [email protected] >>>>>> <mailto:[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] <mailto:[email protected]> >>>>> To unsubscribe send an email to [email protected] >>>>> <mailto:[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] <mailto:[email protected]> >>>> To unsubscribe send an email to [email protected] >>>> <mailto:[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] <mailto:[email protected]> >>> To unsubscribe send an email to [email protected] >>> <mailto:[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] <mailto:[email protected]> >> To unsubscribe send an email to [email protected] >> <mailto:[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!
