[OpenSIPS-Users] number of opensips children

[Stanisław Pitucha]

2009/12/14 Jeff Pyle <jpyle at fidelityvoice.com>:
> I'm trying to determine the "proper" number of opensips children for my
> setup.

Unless you supply telephony to everyone in a small city, it will be below 32 ;)

> I'm having trouble understanding which operations effectively block
> or occupy a process until completion, and which ones allow a process to
> handle other traffic.

All operations "block". When a packet comes in, one process will get
it and will do nothing else, apart from running the config, with this
particular message as the context. That means, if you're running a db
query, the process owning the packet will sleep and do nothing.

> My theory thus far has been to run more children than I should ever need so
> then I don't have to worry about any blocking.  But 150+ children later
> across three proxies and I'm afraid my DB server is unhappy with so many
> connections from FreeRadius and Opensips.

150 * 3 connections to the db? If it's mysql, then yes - it's very
unhappy. mysqltuner.pl will probably show you that the maximal memory
usage is way over your RAM size ;) Assuming you have max connections >
450 and large key buffers - but then, if you don't have big enough key
caches, that's the first spot for optimisation.

> Is it message-based?  That is, does a child process a single message until
> it ships out with t_relay or similar?  In this case, how do things like
> siptrace or accounting impact a child's ability to process other messages?

This. But I'm not sure what siptrace / acc effect are you talking
about. If you need to log the message, it will block the process -
that's pretty much it.

Anyways - my recommendation would be to:
1. Have a look at the benchmark module. Measure your standard messages
processing time (INVITE and REGISTER will be the longest)
2. If you're using mysql, but not the newest opensips - go grab it now
and experience the prepared statements boost :)
3. Calculate how many messages do you *really* need / want to push in
a normal and peek time.

For example, lets say that you use only invites (no registration) -
and can process a request in 200ms and a response in 50ms. (that's
probably somewhere between 10 and 100 times the real amount of time
needed, depending on your database usage) For a normal call you need
INVITE, 407, INVITE, 180, 200, ACK, BYE, 200 -- around 1s in total.
That means with 150 processes you can push complete 150 calls per
second (with authorisation and hangup). With a typical call taking
~4min, you will theoretically support 60*4*150 ==... 36 thousands open
calls. Theoretically, because your CPU probably won't be able to
handle 150 power-hungry processes at the same time.

In reality, with only the dialog database, or by using some custom
in-memory storage, you'll get an average processing time of 1ms /
request. And with any storage, the database should die, before
opensips even notices there is any serious work to do...

These are of course back of a napkin type calculations and don't take
them too seriously, but you'll find out that 150 is way too much.
Measure your processing time, measure your sip packets per second on
the interface... check how many processes do you need in your worst
time of the day.

-- 
KTHXBYE,

Stanisław Pitucha, Gradwell Voip Engineer