[OpenSIPS-Users] number of opensips children

[Bogdan-Andrei Iancu]

Hi Brian,

The test I mentioned was done with UDP.

The messages you are seeing means that the TCP MANAGER process sees that 
all the TCP WORKER processes are already processing other messages, so 
no one is free (idle), so , it will queue the current active connection 
to one of the TCP WORKERs...
There is nothing wrong with this, it is the normal way it works - of 
course, if you have too few TCP workers, the probability to have queuing 
is higher.

In UDP the queueing is not visible at application level as it is done by 
the kernel in the receive buffer that is assigned to the socket.

In TCP the queueing is visible as there is a single TCP MANAGER process 
managing the connections (detecting the reads, connects, etc) which is 
quite fast (not doing any processing) -> the queueing is moved between 
the TCP MANAGER and TCP WORKERS.

Also, to be sure you got it right, there is no relation between the TCP 
WORKER and a connection. A TCP WORKER process is just reading and 
processing a SIP message at a certain time. Next SIP message from the 
same connection may end up in a different TCP WORKER proc.

and this has nothing to do with the tcp_persistent_flag.

Regards,
Bogdan

opensipslist at encambio.com wrote:
> Hello Bogdan,
>
> An mer., déc  23, 2009, Bogdan-Andrei Iancu schrieb:
>   
>> opensips at encambio.com wrote:
>>     
>>> An ven., déc 18, 2009, Bogdan-Andrei Iancu schrieb:
>>>       
>>>> To see what processes you have and what they are doing, do:
>>>>
>>>> opensipsctl fifo ps
>>>>
>>>>         
>>>   # opensipsctl fifo ps
>>>   Process::  ID=0 PID=24975 Type=attendant
>>>   Process::  ID=1 PID=24977 Type=SIP receiver udp:123.234.210.1:5060
>>>   Process::  ID=2 PID=24978 Type=time_keeper
>>>   Process::  ID=3 PID=24979 Type=timer
>>>   Process::  ID=4 PID=24980 Type=MI FIFO
>>>
>>> [...]
>>>
>>> My gut feeling is that having four UDP listening processes and four
>>> TCP listening processes is about right for us, because we only have
>>> a handful of UACs participating infrequently (5 calls per day.)
>>>   
>>>       
>> Actually that is more than needed - during some performance tests (only 
>> simply call relaying) we managed to put 6K cps in a single process.
>>
>>     
> I have eight TCP listeners configured and about sixteen UACs are
> connected. I get a ton of these warnings whenever REGISTER or INVITE
> messages come in:
>
>   Feb 02 18:17:22 name.host.tld <warning> opensips[02126]: WARNING:core:send2child: no free tcp receiver, connection passed to the leastbusy one (1)
>   Feb 02 18:17:25 name.host.tld <warning> opensips[02126]: WARNING:core:send2child: no free tcp receiver, connection passed to the leastbusy one (1)
>
> Because you mentioned that you benchmarked 6K CPS with a single
> process (was it TCP?), I'd like to know if you got as many warnings
> as well. One question is:
>
>   What does 'free tcp receiver' mean? I assumed that listening
>   TCP ports were free to accept as many connections as needed.
>
> By the way, each of the 16 UACs registered to the 8 TCP listener
> processes is avoiding NAT problems by keeping the TCP connection
> open by setting the tcp_persistent_flag.
>
> Is OpenSIPS expecting there to be at least one TCP listener process
> which is not encumbered by the tcp_persistent_flag?
>
> Regards,
> Brian
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>   


-- 
Bogdan-Andrei Iancu
www.voice-system.ro