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 [email protected] wrote: > Hello Bogdan, > > An mer., déc 23, 2009, Bogdan-Andrei Iancu schrieb: > >> [email protected] 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 > [email protected] > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > -- Bogdan-Andrei Iancu www.voice-system.ro _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
