[SR-Users] Re: Kamailio not receiving packets on high CPS

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 &lt;sergio.charrua(a)voip.pt&gt; 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&gt; 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 sr-users(a)lists.kamailio.org&gt; wrote: sr-users(a)lists.kamailio.org&gt; wrote: performs so badly that there is lots of improvement to be squeezed out of optimising that even a little. sr-users(a)lists.kamailio.org 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!