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!
