19 Dec
2024
19 Dec
'24
12:24 p.m.
On Dec 19, 2024, at 12:04 pm, Ben Kaufman
<bkaufman(a)bcmone.com> wrote:
In this case, the "moving food around on the plate" is moving the process
blocking of the http request (which is just wait time) to increased memory usage by
storing the request in memory. The number of message able to be handled over a sustained
period increases (full stop). Of course there' still an upper bound based on memory
and that should be considered. It's not a "limitless fix", but buy creating
a queue for the requests in memory the upper bound gets increased.
I think we've had this polemic before. Yes, the upper bound is increased in some
non-zero amount, but the returns to actual call throughput per se can be marginal vs just
increasing core children drastically, just depending on the exact parameters of the
situation. Increasing core children invites contention problems beyond a certain point,
and the same is true of background async workers.
There are better and worse ways of dealing with the latter; individuated mqueues are a
good solution. core_hash() over Call-ID helps with pseudo-random distribution over
independent pipelines to background workers, versus having them share queue lock.
The best use-case for background async workers is for stuff that isn't in the critical
path of call processing and is highly deferrable, such as call accounting. Otherwise, the
results aren't that great in the end, if throughput is your top concern. Alexis
Fidalgo said it:
"[...] still 'hiding' the problem. Improves? Yes. Fixes? Not at all."
-- Alex
--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: https://evaristesys.com
Tel: +1-706-510-6800