You are viewing a plain text version of this content. The canonical link for it is here.
Posted to httpclient-users@hc.apache.org by Steve Terrell <St...@guideworkstv.com> on 2007/02/08 21:27:15 UTC
Is this a good idea?
Folks,
I think I am losing an argument at work. A coworker is implementing
some code that will be used to call a servlet. HttpClient is the tool of
choice, of course. The code he is writing must handle multiple requests
in parallel, thus he will be using the MultiThreadedConnectionManager.
However, he is proposing to channel all his requests through a
singleton.
I just don't see how that will work. I am convinced the singleton
will have the effect of serializing the requests, since each request
will only get processed when the singleton gets a time slice from the
jvm. Am I nuts for thinking the singleton will be a bottleneck?
--Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: Is this a good idea?
Posted by Julius Davies <ju...@cucbc.com>.
Hi, Steve,
Depends if "synchronized" is used on any of your Singleton's methods.
If not, then your calls will probably not get serialized.
You are right to be concerned about accidental serialization, but you'll
probably be okay this time. Just test it out. An easy way to test is:
in the servlet
======================
public void doGet( HttpServletRequest rq, HttpServletResponse rx )
{
try {
Thread.sleep( 10000 );
} catch ( InterruptedException ie ) {}
}
in the client
======================
Runnable r = new Runnable() {
public void run() {
long now = System.currentTimeMillis();
MySingleton instance = MySingleton.getInstance();
instance.doHttpCall();
long duration = System.currentTimeMillis() - now;
System.out.println( "I took " + duration + "ms" );
}
};
new Thread( r ).start();
new Thread( r ).start();
new Thread( r ).start();
new Thread( r ).start();
new Thread( r ).start();
new Thread( r ).start();
If you see results like:
==========================
I took 10028 ms
I took 20121 ms
I took 29994 ms
I took 30001 ms
I took 40014 ms
I took 50512 ms
Then you are accidentally serializing.
yours,
Julius
On Thu, 2007-08-02 at 15:27 -0500, Steve Terrell wrote:
> Folks,
> I think I am losing an argument at work. A coworker is implementing
> some code that will be used to call a servlet. HttpClient is the tool of
> choice, of course. The code he is writing must handle multiple requests
> in parallel, thus he will be using the MultiThreadedConnectionManager.
> However, he is proposing to channel all his requests through a
> singleton.
> I just don't see how that will work. I am convinced the singleton
> will have the effect of serializing the requests, since each request
> will only get processed when the singleton gets a time slice from the
> jvm. Am I nuts for thinking the singleton will be a bottleneck?
>
>
>
> --Steve
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
>
--
Julius Davies, Senior Application Developer, Product Development
T 416-652-0183 | juliusdavies@cucbc.com
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: Is this a good idea?
Posted by sebb <se...@gmail.com>.
On 08/02/07, Steve Terrell <St...@guideworkstv.com> wrote:
> Folks,
> I think I am losing an argument at work. A coworker is implementing
> some code that will be used to call a servlet. HttpClient is the tool of
> choice, of course. The code he is writing must handle multiple requests
> in parallel, thus he will be using the MultiThreadedConnectionManager.
> However, he is proposing to channel all his requests through a
> singleton.
> I just don't see how that will work. I am convinced the singleton
> will have the effect of serializing the requests, since each request
> will only get processed when the singleton gets a time slice from the
> jvm. Am I nuts for thinking the singleton will be a bottleneck?
[Not sure this is strictly an HttpClient question]
Surely it depends on what the singleton is?
If the singleton is thread-safe without needing sychronisation, then
threads will not impede each other.
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: Is this a good idea?
Posted by Bindul Bhowmik <bi...@gmail.com>.
Steve,
On 2/8/07, Steve Terrell <St...@guideworkstv.com> wrote:
> Folks,
> I think I am losing an argument at work. A coworker is implementing
> some code that will be used to call a servlet. HttpClient is the tool of
> choice, of course. The code he is writing must handle multiple requests
> in parallel, thus he will be using the MultiThreadedConnectionManager.
> However, he is proposing to channel all his requests through a
> singleton.
> I just don't see how that will work. I am convinced the singleton
> will have the effect of serializing the requests, since each request
> will only get processed when the singleton gets a time slice from the
> jvm. Am I nuts for thinking the singleton will be a bottleneck?
I am afraid that is not exactly true. If multiple threads are sending
in the requests, the method(s) in the singleton that executes the
request will run in all those threads in parallel. The singleton
however will have to take on the additional overhead of synchronizing
access to any fields in the singleton that get modified during the
request execution, and also for state management (if any).
Regarding the executing in a time slice from the JVM, any
multi-threaded application on a single CPU machine works only on time
slices of the CPU. I don't see how a singleton makes a difference
here.
>
> --Steve
>
Regards,
Bindul
--
Bindul Bhowmik
MindTree Consulting Ltd.
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
RE: Is this a good idea?
Posted by Roland Weber <RO...@de.ibm.com>.
Hi Steve,
> Well, that's the thing. The HttpState will be wrapped up in the
> singleton. Some of the servers we support will allow up to 32
> simultaneous threads of execution. How will that work when all posts are
> done via a singleton?
The state is required twice for each execution: just before
the request is sent and just after the response header is
received. During the sending and during the response processing,
the state is not accessed and the threads will not synchronize
there.
If you use different HttpClient objects, you will have separate
HttpState objects, too. If that is what you want, you can keep
the HttpClient singleton and have each thread keep it's own state.
That is less overhead than having a connection manager per thread.
hope that helps,
Roland
RE: Is this a good idea?
Posted by Tatu Saloranta <co...@yahoo.com>.
--- Steve Terrell <St...@guideworkstv.com>
wrote:
> Well, that's the thing. The HttpState will be
> wrapped up in the
> singleton. Some of the servers we support will allow
> up to 32
> simultaneous threads of execution. How will that
> work when all posts are
> done via a singleton?
In addition to conceptual discussion, you might just
want to go ahead and write a simple stress test, with
N threads doing end-to-end requests against a simple
server/service. You can also add artifical latency on
server-side. And on client side, you can try out
difference between singleton approach, and per-thread
instance approach.
Based on discussion so far, there's a good change
there might not be significant difference either way;
and specifically no significant benefit from
non-singleton approach. However, if something was
missing from problem description, this should prove
the problem as well as perhaps also point the
bottleneck (just profile on client side, and/or take
thread dumps during test to see where locking is
done).
It's often a good idea to empirically try out
approaches -- results are regularly surprising as
intuition is not always best guide regarding
performance and scalability.
-+ Tatu +-
____________________________________________________________________________________
Looking for earth-friendly autos?
Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center.
http://autos.yahoo.com/green_center/
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
RE: Is this a good idea?
Posted by Steve Terrell <St...@guideworkstv.com>.
Well, that's the thing. The HttpState will be wrapped up in the
singleton. Some of the servers we support will allow up to 32
simultaneous threads of execution. How will that work when all posts are
done via a singleton?
--Steve
-----Original Message-----
From: Roland Weber [mailto:ROLWEBER@de.ibm.com]
Sent: Friday, February 09, 2007 1:14 AM
To: HttpClient User Discussion
Subject: Re: Is this a good idea?
Hello Steve,
> I think I am losing an argument at work. A coworker is implementing
> some code that will be used to call a servlet. HttpClient is the tool
of
> choice, of course. The code he is writing must handle multiple
requests
> in parallel, thus he will be using the MultiThreadedConnectionManager.
> However, he is proposing to channel all his requests through a
> singleton.
This is exactly how HttpClient is supposed to be used. Each thread
that calls the singleton HttpClient will get it's own connection from
the MTHCM (assuming the connection limits are chosen appropriately).
MTHCM is internally synchronized.
You only have to take care about HttpState. HttpClient holds a single
default HttpState, which is also synchronized internally. If it's OK
for all the threads to share one state, that's fine. Otherwise, each
thread has to keep it's own HttpState and pass it to execute().
hope that helps,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: Is this a good idea?
Posted by Roland Weber <RO...@de.ibm.com>.
Hello Steve,
> I think I am losing an argument at work. A coworker is implementing
> some code that will be used to call a servlet. HttpClient is the tool of
> choice, of course. The code he is writing must handle multiple requests
> in parallel, thus he will be using the MultiThreadedConnectionManager.
> However, he is proposing to channel all his requests through a
> singleton.
This is exactly how HttpClient is supposed to be used. Each thread
that calls the singleton HttpClient will get it's own connection from
the MTHCM (assuming the connection limits are chosen appropriately).
MTHCM is internally synchronized.
You only have to take care about HttpState. HttpClient holds a single
default HttpState, which is also synchronized internally. If it's OK
for all the threads to share one state, that's fine. Otherwise, each
thread has to keep it's own HttpState and pass it to execute().
hope that helps,
Roland