23 Dec
2024
23 Dec
'24
6:27 a.m.
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 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
<sr-users(a)lists.kamailio.org> wrote:
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users(a)lists.kamailio.org
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only
to the sender!
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:
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users(a)lists.kamailio.org
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply
only to the sender! 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
> <sergio.charrua(a)voip.pt> 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
> <sr-users(a)lists.kamailio.org> 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
> > <sr-users(a)lists.kamailio.org> wrote:
> > >
> > >
> > >> On Dec 19, 2024, at 1:06 pm, Calvin E. via sr-users
> > <sr-users(a)lists.kamailio.org> 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 -- sr-users(a)lists.kamailio.org
> > > To unsubscribe send an email to
> > sr-users-leave(a)lists.kamailio.org
> > > Important: keep the mailing list in the recipients, do
> > not reply only to the sender!
> >
> > __________________________________________________________
> > Kamailio - Users Mailing List - Non Commercial Discussions
> > -- sr-users(a)lists.kamailio.org
> > To unsubscribe send an email to
> > sr-users-leave(a)lists.kamailio.org
> > Important: keep the mailing list in the recipients, do not
> > reply only to the sender!
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users(a)lists.kamailio.org
To unsubscribe send an email to
sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not
reply only to the sender!
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions --
sr-users(a)lists.kamailio.org
To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply
only to the sender!