[Serusers] Questions about ser

[Michael Ulitskiy]

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 at acedsl.com> wrote:
> > On Monday 25 July 2005 01:47 pm, Michael Ulitskiy 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...
> > 
> > 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 :-)).
> > >
> > 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.
> > 
> > > > 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 at lists.iptel.org
> > http://lists.iptel.org/mailman/listinfo/serusers
> > 
> 
> 
> -- 
> Greg Fausak
> greg at thursday.com
>