[Serusers] Questions about ser

Jan Janak jan at iptel.org
Mon Jul 25 14:21:25 CEST 2005


On 24-07-2005 17:05, Michael Ulitskiy wrote:
> On Saturday 23 July 2005 06:20 pm, Jan Janak wrote:
> > On 18-07-2005 15:43, Michael Ulitskiy wrote:
> > > Hello,
> > > 
> > > I'm using several modules that access a database.
> > > I've noticed that when I start ser in forked mode with
> > > "children=8", it generates 62 connections to database.
> > > Does every child open a separate set of database handles
> > > (one for every module)?
> > 
> >    Yes.
> > 
> > > I remember I saw on the mailing list advises to run 
> > > ser with hundreds of children to avoid problems when no workers
> > > are available to process a message. If my guess is true it would
> > > generate hundreds (or even thousands) of database connections.
> > > I'm really interested to hear how people out there deal with it.
> > 
> >   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.

> Also has connection pool been implemented (or are there plans to implement it) for postgres?  
> This is very important for me as I need to use it.

  Yes, there is a plan to use the connection pool in postgres as well.

    Jan.




More information about the sr-users mailing list