<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1250"><title>Re: [OpenSIPS-Users] number of opensips children</title>
</head>
<body>
<font face="Tahoma, Verdana, Helvetica, Arial"><span style="font-size:10pt">Stanisław,<br>
<br>
This is absolutely fantastic information!! A bit more details about my implementation, if for no other purpose than to illustrate to myself I’m not completely insane... All the DB operations involved in routing a call (usrloc, auth, least-cost routing, etc) take place in a mysql cluster. No DB problems here I can detect. All the write-heavy operations (siptrace, acc via FreeRadius) go to a master half of a master/slave configuration. All tables are InnoDB — the server has experienced some attempts at InnoDB optimization. I took a look at the MySQL 5.1 Sys Variable page for a better understanding of the key cache setting. It looks like the “key_buffer_size” variable is for MyISAM only. I think the InnoDB equivalent is innodb_buffer_pool_size. I’ve got it set to 2G. I’m still learning how to read the server stats to determine if that’s enough. <br>
<br>
The Opensips side consists of three proxies for a total of about 100 children (not 150, my mistake). The proxies have different uses so an average call touches only two of the three. And no, not for a city of any size. Ha! Each proxy lives in its own Xen paravirtualized guest on the same 8-core host. The load average of any of them rarely exceeds 0.01, so no issue there. Each VM also contains its own mysqld cluster front-end, and its own instance of FreeRadius for accounting. I’ve got another 176 DB connections to that master mysql box from all the FreeRadius processes. Not sure why; that seems high even to me. My goal there was to have on DB connection per Opensips process. Anyway, the master machine does report near 300 concurrent connections. All that machine does is write and update InnoDB tables, and replicate to the slave.<br>
<br>
So one process can handle the processing of one message at a time. The process will not clear (accept another message) until all operations are completed, including routing out a network interface, finishing any module’s db writes, etc. Sounds simple enough. I’ll look into the benchmark module to get some numbers on my particular config on each of the proxies. I’m thinking network captures would provide a good indicator as well, by comparing the arrival and departure times of the request? I am running 1.5 and 1.6. All prepared statements I believe. Good times here.<br>
<br>
Unfortunately my napkin ran out of batteries so I had to fire up the Gnome Calculator. Once I get some measurements from either the benchmark module or from tshark I’ll see what it can crunch for me.<br>
<br>
Hopefully others will find this thread useful in the planning of their own systems. Or, as in my case, unveil the gross mis-planning.<br>
<br>
<br>
- Jeff<br>
<br>
<br>
<br>
On 12/14/09 6:13 PM, "Stanisław Pitucha" <<a href="viraptor@gmail.com">viraptor@gmail.com</a>> wrote:<br>
<br>
<font color="#0000FF">> 2009/12/14 Jeff Pyle <<a href="jpyle@fidelityvoice.com">jpyle@fidelityvoice.com</a>>:
> I'm trying to determine the <br>
> "proper" number of opensips children for my
> setup.
Unless you supply <br>
> telephony to everyone in a small city, it will be below 32 ;)
> I'm having <br>
> trouble understanding which operations effectively block
> or occupy a process <br>
> until completion, and which ones allow a process to
> handle other <br>
> traffic.
All operations "block". When a packet comes in, one process will <br>
> get
it and will do nothing else, apart from running the config, with <br>
> this
particular message as the context. That means, if you're running a <br>
> db
query, the process owning the packet will sleep and do nothing.
> My <br>
> theory thus far has been to run more children than I should ever need so
> <br>
> then I don't have to worry about any blocking. But 150+ children later
> <br>
> across three proxies and I'm afraid my DB server is unhappy with so many
> <br>
> connections from FreeRadius and Opensips.
150 * 3 connections to the db? If <br>
> it's mysql, then yes - it's very
unhappy. mysqltuner.pl will probably show you <br>
> that the maximal memory
usage is way over your RAM size ;) Assuming you have <br>
> max connections >
450 and large key buffers - but then, if you don't have big <br>
> enough key
caches, that's the first spot for optimisation.
> Is it <br>
> message-based? That is, does a child process a single message until
> it <br>
> ships out with t_relay or similar? In this case, how do things like
> <br>
> siptrace or accounting impact a child's ability to process other <br>
> messages?
This. But I'm not sure what siptrace / acc effect are you <br>
> talking
about. If you need to log the message, it will block the process <br>
> -
that's pretty much it.
Anyways - my recommendation would be to:
1. Have a <br>
> look at the benchmark module. Measure your standard messages
processing time <br>
> (INVITE and REGISTER will be the longest)
2. If you're using mysql, but not <br>
> the newest opensips - go grab it now
and experience the prepared statements <br>
> boost :)
3. Calculate how many messages do you *really* need / want to push <br>
> in
a normal and peek time.
For example, lets say that you use only invites <br>
> (no registration) -
and can process a request in 200ms and a response in 50ms. <br>
> (that's
probably somewhere between 10 and 100 times the real amount of <br>
> time
needed, depending on your database usage) For a normal call you <br>
> need
INVITE, 407, INVITE, 180, 200, ACK, BYE, 200 -- around 1s in total.
That <br>
> means with 150 processes you can push complete 150 calls per
second (with <br>
> authorisation and hangup). With a typical call taking
~4min, you will <br>
> theoretically support 60*4*150 ==... 36 thousands open
calls. Theoretically, <br>
> because your CPU probably won't be able to
handle 150 power-hungry processes <br>
> at the same time.
In reality, with only the dialog database, or by using some <br>
> custom
in-memory storage, you'll get an average processing time of 1ms <br>
> /
request. And with any storage, the database should die, before
opensips even <br>
> notices there is any serious work to do...
These are of course back of a <br>
> napkin type calculations and don't take
them too seriously, but you'll find <br>
> out that 150 is way too much.
Measure your processing time, measure your sip <br>
> packets per second on
the interface... check how many processes do you need in <br>
> your worst
time of the day.
--
KTHXBYE,
Stanisław Pitucha, Gradwell Voip <br>
> Engineer
_______________________________________________
Users mailing <br>
> list
<a href="Users@lists.opensips.org">Users@lists.opensips.org</a>
<a href="http://lists.opensips.org/cgi-bin/mailman/listin">http://lists.opensips.org/cgi-bin/mailman/listin</a><br>
> fo/users
<br>
</font></span></font>
</body>
</html>