On 6/12/20 8:03 PM, Calvin Ellison wrote:
That's been the point of this discussion. Unfortunately, there answers
so far have added to up "keep changing settings until you find what
works best" and "buffers are a Ponzi scheme" despite and immediate 3x
performance increase.
Perhaps if one adopts a rather esoteric understanding of "performance
increase" ... in principle, queueing more packets indicates the
opposite. In that light, one could look at a lower receive queue depth
as an optimisation, actually.
One should see the forest for the trees, instead of cultivating a myopic
preoccupation with short-term, stop-gap solutions.
Two things are logically possible:
(1) The receive queue backlog keeps stacking up until the size of 16.7m
is exhausted as well; this is clearly not happening, or it would not be
triumphantly claimed as a solution;
(2) The higher buffer provides the elasticity needed to cope with
stochastic I/O wait conditions which, for a given base CPS load, occur
within a certain range of latencies and at a certain frequency
distribution. Because the blocking conditions are not always uniformly
present--they're stochastic, after all--in those low-tide moments, the
receive queue drains.
The larger buffer solves #2, but not by way of providing for a
"performance increase". Nothing is performing better. It's a lever--a
quite imperfect one--to cope with the fact that something is performing
_quite poorly_. However, fortunately for you, it happens on an
intermittent basis, otherwise you'd have quickly encountered scenario #1.
#2 is a better and more manageable problem than #1, in strictly relative
terms, but both are pathological and need to be addressed. To say that
this amounts to a "tuning" or "optimisation" that yields a "performance
increase" is profoundly misleading.
-- Alex
--
Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
