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!