hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vimarsh Vasavada" <v.vasav...@popnet.co.in>
Subject RE: Connection Pooling/Piplining
Date Thu, 01 Apr 2004 09:06:22 GMT
Thanks all.
I am running the test-simulation .
Will post results for 
1. Sun implementation
2. Jakarta.MultiThreadedConnectionManager.

lets's see.

> -----Original Message-----
> From: Kalnichevski, Oleg [mailto:oleg.kalnichevski@bearingpoint.com]
> Sent: Thursday, April 01, 2004 2:32 PM
> To: Commons HttpClient Project
> Subject: RE: Connection Pooling/Piplining
> 
> 
> Vim,
> 
> > 1. Managing worker threads.[H/W,OS and App Server configuration is
the
> > place to find solution]
> 
> Having a pool of worker threads instead of spawning a dedicated thread
per
> request / connection may well be a good investment for this kind of
> application. This is something HttpClient will not be able to help you
> with, though.
> 
> > 2. Managing Connections between S1 and S2 is a second one..that's
where
> > I am baffled..as sun's raw implementation is not much of help to
> > consider such load..
> 
> MultiThreadedConnectionManager does support connection pooling out of
the
> box (so to speak). You can fine-tune the behaviour of the
> MultiThreadedConnectionManager class by defining the total maximum
number
> of connections in the pool as well the maximum number of connections
per
> host.
> 
> 
> For more details see
> 
> <http://jakarta.apache.org/commons/httpclient/threading.html>
> 
> Hope this helps
> 
> Oleg
> 
> -----Original Message-----
> From: Vimarsh Vasavada [mailto:v.vasavada@popnet.co.in]
> Sent: Thursday, April 01, 2004 10:56
> To: Commons HttpClient Project
> Subject: RE: Connection Pooling/Piplining
> 
> 
> Well 1,00,000 threads is the worst-maximum-load-case.
> But least-load case we evaluate is 1000 threads..
> Problem is divisible into 2 sub-probs :
> 1. Managing worker threads.[H/W,OS and App Server configuration is the
> place to find solution]
> 2. Managing Connections between S1 and S2 is a second one..that's
where
> I am baffled..as sun's raw implementation is not much of help to
> consider such load..
> 
> HARDWARE PARAMETER SYSTEM
> Class Server Class or Higher End Desktop
> Processor PIV 2.4 GHz
> 
> Memory 1 GB RAM
> Hard Disk IDE 40GB 7200 rpm
> Network Dual LAN card (one for live IP and other for internal IP)
> 
> Application Server : jBoss 3.x with integrated Tomcat 4.x
> JDK 1.3.1
> HTTP Server : Apache 2.x with jBoss
> RDBMS       : MS SQL Server 2000
> O/S Windows 2000 Server with SP3
> 
> 
> 
> > -----Original Message-----
> > From: Kalnichevski, Oleg [mailto:oleg.kalnichevski@bearingpoint.com]
> > Sent: Thursday, April 01, 2004 1:44 PM
> > To: Commons HttpClient Project
> > Subject: RE: Connection Pooling/Piplining
> >
> 
> >
> 
> > Hi Vim
> > Are you absolutely sure you need all 100,000 threads running
> > simultaneously? Probably you should approach the problem from a
> different
> > angle and try to pool the worker threads rather than pooling HTTP
> > connections?
> >
> 
> > Oleg
> >
> 
> > -----Original Message-----
> > From: Vimarsh Vasavada [mailto:v.vasavada@popnet.co.in]
> > Sent: Thursday, April 01, 2004 9:27
> > To: Commons HttpClient Project
> > Subject: Connection Pooling/Piplining
> >
> 
> >
> 
> > Hello all.
> > We have following challenge to address :
> > 1. We have 2 JBOSS Servers, say, S1 and S2
> > 2. There will be 1,00,000 distinct-client-threads fired to
> > S1/TalkToS2.jsp/
> > 3. S1 will have hence virtually 1,00,000-threads attempting to
> exchange
> > request/response with S2 only.
> >
> 
> > Now questions :
> > 1. how do we realize Connection Pooling ?
> > 2. Can MultiThreadedConnectionManager be of help to realize
connection
> > pooling?
> > 3. Since for all client-threads we need to make connection to single
> > server S2,can we realize Piplining?
> >
> 
> > Thanks in advance
> > vim
> >
> 
> >
> 
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-httpclient-dev-
> > unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-httpclient-dev-
> > help@jakarta.apache.org
> >
> 
> >
> 
> >
>
************************************************************************
> **
> > *************************
> > The information in this email is confidential and may be legally
> > privileged.  Access to this email by anyone other than the intended
> > addressee is unauthorized.  If you are not the intended recipient of
> this
> > message, any review, disclosure, copying, distribution, retention,
or
> any
> > action taken or omitted to be taken in reliance on it is prohibited
> and
> > may be unlawful.  If you are not the intended recipient, please
reply
> to
> > or forward a copy of this message to the sender and delete the
> message,
> > any attachments, and any copies thereof from your system.
> >
>
************************************************************************
> **
> > *************************
> >
> 
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-httpclient-dev-
> > unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-httpclient-dev-
> > help@jakarta.apache.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-httpclient-dev-
> unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-httpclient-dev-
> help@jakarta.apache.org
> 
> 
>
************************************************************************
**
> *************************
> The information in this email is confidential and may be legally
> privileged.  Access to this email by anyone other than the intended
> addressee is unauthorized.  If you are not the intended recipient of
this
> message, any review, disclosure, copying, distribution, retention, or
any
> action taken or omitted to be taken in reliance on it is prohibited
and
> may be unlawful.  If you are not the intended recipient, please reply
to
> or forward a copy of this message to the sender and delete the
message,
> any attachments, and any copies thereof from your system.
>
************************************************************************
**
> *************************
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-httpclient-dev-
> unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-httpclient-dev-
> help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-httpclient-dev-help@jakarta.apache.org


Mime
View raw message