RE: Number of connections

[James Bourne <jbourne@MtRoyal.AB.CA>]

On Wed, 17 Apr 2002, Evaristo-Jose Camarero (ECE) wrote:

> 
> Hi James and all:
> 
> Thank you by your help. Can you give me any initial
> values for threads and concurrency to start testing to improve the
> number of connections? We have R.H. Linux 7.1 and OpenLdap 2.0.18.

I think this would depend very much on the demand, and there wouldn't be a
set value to put this at...

I've used netstat to tune these values, for example
netstat -an | grep ":389.*EST" | wc -l
47

So, you currently have about 47 open connections to your
ldap server, try setting the values larger, and set the value of threads a
bit higher then concurrency.  (say threads 80 concurrency 70)?

Regards
James

> 
> Thank you very much,
> 
> /Evaristo
> 
> 
> 
> > -----Original Message-----
> > From: James Bourne [mailto:jbourne@MtRoyal.AB.CA]
> > Sent: Monday, April 15, 2002 9:39 PM
> > To: Evaristo-Jose Camarero (ECE)
> > Cc: 'OpenLDAP-software@OpenLDAP.org'
> > Subject: Re: Number of connections
> > 
> > 
> > On Mon, 15 Apr 2002, Adam Williams wrote:
> > 
> > > >Can anybody tell me how many simultaneous connections can 
> > be served 
> > > >by the openldap server (2.0.23 with Red Hat Linux 7.1).
> > > >I have seen the code and it seems that there is a thread 
> > pool with 32 
> > > >threads. Does it mean that server only can attend 32 
> > connections at the
> > > >same time?
> > > 
> > > Yes.  But answering a request should be very quick,  and 
> > the thread then
> > > processes the next request.  I suppose you could try increasing the
> > > thread pool, but I don't know if that will work.  In actuality (ever
> > > case I've seen) 32 is alot of concurrent queries.
> > > 
> > 
> > Yes, increasing the thread pool does work fine.
> > 
> > You can set the number of threads and concurrent connections with:
> > 
> > threads		<number of threads to run at max>
> > concurrency	<number of concurrent connections to allow>
> > 
> > One other thing to note, slapd uses select, and is therefore 
> > limited to
> > 1024 concurrent connections due to the limit of __FD_SETSIZE 
> > (I ran into
> > this in some scalability testing I was doing).  If it were 
> > using poll then
> > the limit would be more scalable.
> > 
> > Of course, if you can run a read server with 1024 
> > connections, I'm sure
> > you're doing fairly good...
> > 
> > We generally set concurrency slightly less then threads.
> > 
> > Regards
> > James Bourne
> > 
> > -- 
> > James Bourne, Supervisor Data Centre Operations
> > Mount Royal College, Calgary, AB, CA
> > www.mtroyal.ab.ca
> > 
> > **************************************************************
> > ****************
> > This communication is intended for the use of the recipient 
> > to which it is
> > addressed, and may contain confidential, personal, and or privileged
> > information. Please contact the sender immediately if you are not the
> > intended recipient of this communication, and do not copy, 
> > distribute, or
> > take action relying on it. Any communication received in error, or
> > subsequent reply, should be deleted or destroyed.
> > **************************************************************
> > ****************
> > 
> 

-- 
James Bourne, Supervisor Data Centre Operations
Mount Royal College, Calgary, AB, CA
www.mtroyal.ab.ca

******************************************************************************
This communication is intended for the use of the recipient to which it is
addressed, and may contain confidential, personal, and or privileged
information. Please contact the sender immediately if you are not the
intended recipient of this communication, and do not copy, distribute, or
take action relying on it. Any communication received in error, or
subsequent reply, should be deleted or destroyed.
******************************************************************************