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 Christiaan Lamprecht <ch...@googlemail.com> on 2007/12/21 21:43:49 UTC
SSL and concurrency
Hallo all,
Just a quick question on SSL, MultiThreadedHttpConnectionManager and
Keep-Alive if anyone can help.
I've been experimenting with the MultiThreadedExample on the
HTTPClient website
(http://svn.apache.org/viewvc/httpcomponents/oac.hc3x/trunk/src/examples/MultiThreadedExample.java?view=markup)
and it seems that a new SSL connection/session is created for every
thread and the session is re-used within each thread for each
executeMethod call, but of course every time
"httpClient.executeMethod(method);" is called it waits for a reply
before I can make another request within that thread.
Is it possible to additionally make parallel requests within an SSL
session? Perhaps using "executeMethod(HostConfiguration hostconfig,
HttpMethod method, HttpState state)" or one of the others which
provide some state to distinguish between the parallel requests. Or to
set it up in such a way that concurrent threads share an SSL session.
Any help would be much appreciated.
Many thanks
Christiaan
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
Re: SSL and concurrency
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Fri, 2007-12-21 at 20:43 +0000, Christiaan Lamprecht wrote:
> Hallo all,
>
> Just a quick question on SSL, MultiThreadedHttpConnectionManager and
> Keep-Alive if anyone can help.
>
>
> I've been experimenting with the MultiThreadedExample on the
> HTTPClient website
> (http://svn.apache.org/viewvc/httpcomponents/oac.hc3x/trunk/src/examples/MultiThreadedExample.java?view=markup)
> and it seems that a new SSL connection/session is created for every
> thread and the session is re-used within each thread for each
> executeMethod call, but of course every time
> "httpClient.executeMethod(method);" is called it waits for a reply
> before I can make another request within that thread.
>
>
> Is it possible to additionally make parallel requests within an SSL
> session?
Why would you want to do that in the first place? While theoretically it
should be possible for multiple SSL connections to share the same
session ID, I am not sure SUN JSSE provides such possibility.
Oleg
> Perhaps using "executeMethod(HostConfiguration hostconfig,
> HttpMethod method, HttpState state)" or one of the others which
> provide some state to distinguish between the parallel requests. Or to
> set it up in such a way that concurrent threads share an SSL session.
>
>
> Any help would be much appreciated.
>
>
> Many thanks
> Christiaan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
Re: SSL and concurrency
Posted by Christiaan Lamprecht <ch...@googlemail.com>.
> After much reading and looking through the dev mailing list it seems
> that "pipelining" is what I was looking for.
Due to your tip-off of course...
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
Re: SSL and concurrency
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Fri, 2008-01-11 at 16:10 +0000, Christiaan Lamprecht wrote:
> Thanks Ronald,
>
> After much reading and looking through the dev mailing list it seems
> that "pipelining" is what I was looking for. Though saying that, it
> does not seem to be very well supported in general. MozillaZine seems
> to think that pipelining is not very well supported by some servers (I
> assumed pipelining is only a client side concern?) and the java JDK
> (up to 1.5, probably 6 too) does not support it either. Does the new
> HttpCore 4 support it?
Hi Christiaan,
The NIO based HTTP connection classes in HttpCore are fully pipelining
capable. However mainly because the pipelining of entity enclosing
requests and the expect-continue handshake are pretty much mutually
exclusive (well, one _could_ use disable pipelining before executing a
request with expect-continue handshake on and re-enable it afterward,
but I am digressing), we chose to support the expect-continue handshake
required by the HTTP spec instead of the pipelining in all protocol
handlers shipped with HttpCore. Having said that, one could more or less
easily develop custom protocol handlers that do the pipelining at the
expense of the support for the expect-continue handshake.
> (httpcomponents-dev mentioned that it might do
> by now - post made about a year ago) or should I be looking at
> HttpAsync or something else?
>
> And just by the by, I thought NIO can serve more connections than
> using blocking I/O? Or perhaps only when the server is fully loaded?
>
Not necessarily. Blocking I/O tends to perform better than NIO when it
is constantly busy pumping data. NIO on the other hand tends to be much
more efficient when there are lots and lots of connections that sit idle
most of the time, because the system does not have to constantly switch
thread contexts just to check on the status of an I/O operation.
Generally NIO suits better for high-latency scenarios and generally it
can handle more connections because the number of concurrent connections
is not limited by the pool of worker threads.
Hope this helps
Oleg
>
> Thanks again!
> Christiaan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
> For additional commands, e-mail: httpclient-users-help@hc.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
Re: SSL and concurrency
Posted by Christiaan Lamprecht <ch...@googlemail.com>.
Thanks Ronald,
After much reading and looking through the dev mailing list it seems
that "pipelining" is what I was looking for. Though saying that, it
does not seem to be very well supported in general. MozillaZine seems
to think that pipelining is not very well supported by some servers (I
assumed pipelining is only a client side concern?) and the java JDK
(up to 1.5, probably 6 too) does not support it either. Does the new
HttpCore 4 support it? (httpcomponents-dev mentioned that it might do
by now - post made about a year ago) or should I be looking at
HttpAsync or something else?
And just by the by, I thought NIO can serve more connections than
using blocking I/O? Or perhaps only when the server is fully loaded?
Thanks again!
Christiaan
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
Re: SSL and concurrency
Posted by Roland Weber <os...@dubioso.net>.
Hello Christiaan,
> Is it correct to assume that for every (HTTP) connection, mentioned
> above, only 1 request can be made at a time and that the requests can
> be part of the same connection if keep-alive is used (But of course
> multiple HTTP connections can still be made in parallel) If this is
> true then it most probably is for SSL.
Yes, this is true for both.
> Now using a new thread for every request is quite expensive for the
> server, lets say this is mainly due to the new SSL connection that is
> created for every thread, and I would like to make multiple requests
> per SSL connection as well. This is fine as, as long as keep-alive is
> enabled I can make more than one request per SSL connection BUT these
> requests are sequential and so I can't maintain my requested request
> rate if the server does not respond within 1/x seconds.
That is correct. But no matter what you do, a connection can only
be used for coupled request/response pairs. Even with pipelining,
you can't get the response for request 2 until after the response
for request 1. And without pipelining (an optional feature of
servers, btw), you have to receive a response completely before
you can send the next request. Keep-alive will reduce the overhead
of establishing connections, but no more. If a response is not read
within 1/x seconds and the connection returned to the manager, you
have to open a new connection or wait until one becomes available.
If you want to guarantee a fixed rate of requests to the server,
you have to live with an excessive number of connections. If you
decide to use HttpCore-NIO, you can at least reduce the number of
threads. Though that will also reduce the maximum throughput of
your test application, since fewer threads have to serve the same
number of connections.
You can put a bound on the number of connections by defining a
response time limit and aborting connections if the response
isn't received in time. With x requests per seconds and a limit
of n seconds, you'll need at most n*x simultaneous connections.
hope this helps,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
Re: SSL and concurrency
Posted by Christiaan Lamprecht <ch...@googlemail.com>.
Thanks for the quick reply!
> Yes, every thread obtains it's own connection from MTHCM, every
> (HTTP) connection opens a new SSL connection with a separate
> SSL session.
Is it correct to assume that for every (HTTP) connection, mentioned
above, only 1 request can be made at a time and that the requests can
be part of the same connection if keep-alive is used (But of course
multiple HTTP connections can still be made in parallel) If this is
true then it most probably is for SSL.
> Maybe somebody else can provide the missing pieces.
It might also help if I quickly describe some of the problem:
Lets say I'm writing a client to benchmark a server and I want the
client to maintain a load of x req/s on the server. Lets say I use
MTHCM to make a request every 1/x seconds, the threads ensure that the
request rate I want is maintained regardless of what happens on the
server side and so I can say that the server can handle a request rate
of x req/s with an average request response time of y seconds.
Now using a new thread for every request is quite expensive for the
server, lets say this is mainly due to the new SSL connection that is
created for every thread, and I would like to make multiple requests
per SSL connection as well. This is fine as, as long as keep-alive is
enabled I can make more than one request per SSL connection BUT these
requests are sequential and so I can't maintain my requested request
rate if the server does not respond within 1/x seconds.
Now on a more fine grained scale, the server might respond more
quickly to some requests and slower to others but still on average
manage to serve all the requests quicker than I send them (i.e it can
handle that particular load) but I would like a guaranteed req/s on
the client side and not have it intermittently stop sending requests
because of this.
Thank you for reading this far!
Thanks
Christiaan
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org
Re: SSL and concurrency
Posted by Roland Weber <os...@dubioso.net>.
Hello Christiaan,
> I've been experimenting with the MultiThreadedExample on the
> HTTPClient website
> (http://svn.apache.org/viewvc/httpcomponents/oac.hc3x/trunk/src/examples/MultiThreadedExample.java?view=markup)
> and it seems that a new SSL connection/session is created for every
> thread and the session is re-used within each thread for each
> executeMethod call, but of course every time
> "httpClient.executeMethod(method);" is called it waits for a reply
> before I can make another request within that thread.
Yes, every thread obtains it's own connection from MTHCM, every
(HTTP) connection opens a new SSL connection with a separate
SSL session.
> Is it possible to additionally make parallel requests within an SSL
> session?
I'm not that familiar with SSL sessions. If it is possible to open
several SSL connections with the same session, you could do that.
But I guess the SSL session contains the cipher suite and session
key that is negotiated for that specific SSL connection. If that
is the case, you can't have multiple connections using the same
session. And you cannot execute multiple requests over a single
connection in parallel. Pipelining would be the best that the HTTP
specification allows, and that's not supported in HttpClient 3.1
or 4.0.
If I am wrong about the one-to-one relation of SSL connections
and SSL sessions, you could install a SecureProtocolSocketFactory
that creates multiple connections for the same session. That's
easy if you want all connections to share the same session, and
very tricky if you only want some connections to share a session.
Maybe somebody else can provide the missing pieces.
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@hc.apache.org
For additional commands, e-mail: httpclient-users-help@hc.apache.org