[asterisk-dev] [Code Review] Split up SIP UDP receiving and proceeding

[Stefan Schmidt]

Am 12.10.2010 19:13, schrieb Vadim Lebedev:
> Hi,
> 
> I wonder what is the practical difference between packets waiting in  
> kernel queue or internal asterisk queue?
> You economise on deadlok avoidanace code in handle_request_do?
> 
> Thanks
> Vadim
> 
hello vadim,


the differnce is that asterisk only reads one incoming package from the
buffer but maybe send out many packages by processing the scheduler queue.

on heavy load this could cause such situation:

asterisk tries to poke a user (qualify) and sends an option message out.
the client answers but his answer is for example only on the 50. place
in the buffer. without my patch not only one single package would be
read its also direct handled by the sipsock_read function. This means
until this single message is processed no other messages could be
received. after this single message is processed it loops again. what i
have seen and its very easy to reproduce this in 1.6.2 is that
processing incoming messages just took too long until the poke peer
function says the client is unreachable and sends out even more packets
to reach this peer again. as i said this is only something to worry
about under heavy load but this could bring down whole sip handling.

as i have tried to say handling an incoming packet tooks time, more that
i have ever expected and just to make it clearer what i mean i will show
you some values i have seen on the handle_request_do function:

OPTION messages needs an average of 200 to 300 usec. (thats ok if you
have 100 peers. if you have 3000 that would be hard on the limit)
INVITE needs between 1500 and 5000 usec but thats cause of the slow
handle_statechange
REGISTER needs between 15000 and 40000 usec (yes thats 40ms) without
russell bryants astdb patch. with this its about 500 to 800 usec.
SUBSCRIBE was like registers but after my patch they are around 700 usec.

I am not finished with my load testings so i dont know by now if this
really could improve sip message handling.

this review was only cause i needed help with a problem that i had.

next step i will take is to improve handle_statechange handling cause
heavy locking happens there so if this would be much faster than 2 ms
for a single call, the whole processing and lock waiting would be much
better.

and the deadlock avoidance code is not that big problem. i have thought
it would be but its not.

best regards

stefan