[Serusers] Questions about ser

Michael Ulitskiy mdu113 at acedsl.com
Mon Jul 25 18:07:03 CEST 2005


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.
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.
 
> > 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.

Great! Thanks Jan.

>     Jan.
> 
> 

Michael




More information about the sr-users mailing list