On Jul 25, 2005 at 12:07, Michael Ulitskiy
<mdu113(a)acedsl.com> wrote:
On Monday 25 July 2005 08:21 am, Jan Janak
wrote:
>
No, you don't need hundreds of children, usualy 16 is maximu what you
> need. Newer ser versions contain connection pool, so each child will
> open exactly one database connection and it will be reused across
> modules.
What about processing that involves slow DNS queries? I thought this would
eat up available workers quite quickly and further processing will be blocked?
Please correct me if I'm wrong.
You can install local (running on the same host as the proxy) DNS
cache that can also cache negative entries (those that do not exist or
cannot be looked up), such as dnsmasq. This way the slow query would
be performed once and subsequent queries will be answered from the
cache.
Moreover, kernel maintains a queue of incoming SIP requests and it
will continue receiving SIP messages even if all processes are
blocked. The kernel starts to drop incoming SIP messages once the
queue is full.
Well, I guess it's not a solution. It's a workaround at best. I'd vote for
something
apache-like. I.e. master process monitoring the number of idle children and forking
additional as needed. Thanks anyway.
Why not start them all from the beginning? Is not like they will eat a
lot of resources...
Also could you (or someone) give me a rough
estimation on what is the optimal
number of children to serve let's say 10k sip clients as registrar and proxy with
moderately complex config file, but not involving DNS queries? INVITEs may involve
several database queries to a dedicated database server. I understand that the
question is rather vague, I'm just interested in a rough estimation and some
real-world numbers people use.
Try it and if you can see packets in the socket buffers (netstat)
increase the number of children.
I would use 20-50 children.
This it to be on the extra-safe side. I was using 16 children on a
similar system (in terms of number of subscribers) with DNS turned on.
Jan.