[asterisk-dev] scalability issue with realtime lastms update on qualify state change

[Tilghman Lesher]

On Sat, Nov 16, 2013 at 2:02 AM, Olle E. Johansson <oej at edvina.net> wrote:
> Yes, there's one single thread in chan_sip handling all the Qualify and
> inbound sip messages. If we moved the database updates to a background
> thread the situation would improve. Then the monitor thread would just move
> on to the next message, letting another thread wait for the database.

Secondarily, the pokes (qualifies) are sent in each peer thread.  If
instead, a single background thread were sending the qualifies,
(possibly even rate limiting the sending, in order to ensure the
responses can be received on time), that would additionally eliminate
the flapping.  The issue is that the return packets cannot be acted
upon before the expiration time, because the initial poke packets are
sent in parallel, but the responses have to be received serially,
within a single thread.

I disagree with the alternate coding proposal, because it attempts to
code around the problem by turning something off, rather than
attacking the core of the problem, which solves it for everybody.

-Tilghman