2009/12/14 Jeff Pyle <jp...@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 _______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users