25 Jul
2005
25 Jul
'05
8:51 p.m.
Greg,
I'm not aware of 'delay open until used' feature.
Could you please elaborate or point me to the documentation?
Thanks,
Michael
On Monday 25 July 2005 02:32 pm, Greg Fausak wrote:
I ran in to a similar problem with the postgres
driver.
I thought I checked in the 'delay open until used' feature,
which should substantially get rid of all of those database
connections. If I recall correctly, the mysql used to open the database
before forking the children. This created two problems for me,
one was that postgres needed the db connection created after the
fork, and the second was that many of the modules that didn't
even touch the database were also opening channels. The 'delay
open until used' feature simply did the open when a query was done instead
of when the open was done. I was easily running dozens of
SER installations, each with 4 children, all connected to the same
database.
---greg
On 7/25/05, Michael Ulitskiy <mdu113(a)acedsl.com> wrote:
On Monday 25 July 2005 01:47 pm, Michael Ulitskiy
wrote:
Unfortunately this is not an option
for postgres at the moment or I'd definitely
go for it. This is actually was the real reason I started this thread. Due to lack
of connection pool for postgres I need to determine the optimal number
of children. Thanks for the estimation.
--
Greg Fausak
greg(a)thursday.com
> > > > > 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...
Just because sometimes it's hard to predict how many of them will be needed.
And if you grow over time you have a good chance not to notice that the number
needs to be increased until you get a whole lot of customers complaints. And
with this approach it's hard to deal with temporary activity spikes. And probably
more :)
> 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. The "lots of db connections" problem is
solved when using connection pools (or by increasing the maximum
connections in mysql's config :-)).
> You could use also tune the dns timeout
(limit the maximum time a dns
> request can take). For this you would need either unstable (grep NEWS
> for dns_) or to edit your /etc/resolv.conf and set the timeout and
> attempts options and remove the search or domain lines.
>
> Andrei
Michael
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers