Which I agree, http is far away from being the best option, but you know, sometimes there’s no choice, my api consumes 3 external web services from third party apps and there’s no chance to change that. If it were my choice, no http will be involved at least for this
Enviado desde dispositivo móvil > El 27 ago 2024, a la(s) 10:16 a. m., Alex Balashov via sr-users > <[email protected]> escribió: > > >> On Aug 27, 2024, at 8:39 AM, Alexis Fidalgo via sr-users >> <[email protected]> wrote: >> >> I gave up now on the kamailio side (only added more cpu’s and children to >> absorb he shockwave) and working on the API to start caching things in a >> redis and getting the ‘external’ data in a different thread to avoid the >> processing delay. I believe this will be the bigger gain. > > You are certainly correct; this is the area where the juice is "worth the > squeeze". But there are only so many gains you can make in the speed of an > HTTP API call. By its very nature, this mechanism is designed for the > relatively delay-tolerant web economy, not for real-time telecommunications > systems. > > This is not to deny that plenty of real-time telecommunications systems use > HTTP API calls. > > -- Alex > > -- > Alex Balashov > Principal Consultant > Evariste Systems LLC > Web: https://evaristesys.com > Tel: +1-706-510-6800 > > __________________________________________________________ > Kamailio - Users Mailing List - Non Commercial Discussions > To unsubscribe send an email to [email protected] > Important: keep the mailing list in the recipients, do not reply only to the > sender! > Edit mailing list options or unsubscribe: __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to [email protected] Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe:
