[jetty-users] Apache HttpClient vs Java UrlConnection

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[jetty-users] Apache HttpClient vs Java UrlConnection

Joakim Erdfelt-9
Is apache httpclient still viable?
Speaking from experience using both it and standard java UrlConnection on Android (key piece of info there), the standard java UrlConnection is faster in all aspects of http, from establishing the connection, handling the streams, authenticating, and even concurrent active connections than the Apache HttpClient on the same device.  No amount of tweaking of the apache httpclient could even get close to the standard naive implementation using Java UrlConnection.

Why is that?  Really, why?  Before this experience i was a huge fan of apache httpclient (i like the control I have over the http transactions), but now...
--
Joakim Erdfelt



On Thu, May 24, 2012 at 2:32 PM, Otis Gospodnetic <[hidden email]> wrote:
Thanks Simone,

I think Vert.x has more than just a spike of tweets, though :)

What I'm after is something that can handle a high number of concurrent connections from an HTTP client (e.g. Apache HttpClient) to an HTTP server (Jetty?).  You can see in my sig why I'm interested in this....

Thanks,
Otis 
----
Performance Monitoring for Solr / ElasticSearch / HBase - http://sematext.com/spm 




----- Original Message -----
> From: Simone Bordet <[hidden email]>
> To: Otis Gospodnetic <[hidden email]>; JETTY user mailing list <[hidden email]>
> Cc:
> Sent: Thursday, May 24, 2012 5:16 PM
> Subject: Re: [jetty-users] Vert.x-like functionality in Jetty?
>
> Hi,
>
> On Thu, May 24, 2012 at 8:59 PM, Otis Gospodnetic
> <[hidden email]> wrote:
>>  Hi,
>>
>>  Are you saying CometD provides the same scalability and concurrency Vert.x
>>  claims to provide?
>
> Look carefully at the Vert.x benchmark: they open 6 (six) connections
> and pipeline on each 2000 requests.
> How realistic is such traffic ?
>
> I am sure Vert.x 1.0 is a fine framework and all that, but I'd like to
> see a more realistic benchmark before expressing an opinion.
> That is what we tried to achieve with the CometD benchmark, which
> implements a chat application, with 1k, 5k 10k up to 200k connected
> users to a single server and different message rates.
>
>>  If CometD provides (and has been providing for years) the high scalability
>>  and concurrency support, what's all Vert.x all about?
>
> Ask them :)
> To me, it's about diversity.
> Why there exist more than one servlet container ?
>
>>  Is it the case that
>>  while CometD may provide the same stuff Vert.x does, CometD is not widely
>>  known or is at least not as popular? (if so, that can be critical for its
>>  future)
>
> Not sure what Vert.x provides yet (have not looked in details), but
> CometD provides authentication hooks, fine-grained access control,
> message acknowledgment and guaranteed server-to-client message
> delivery on short network failures, a fully extensible framework,
> transport independence and fallback, automatic reconnections, and I
> can continue for a while.
>
> I heard about Vert.x one month or less ago, actually, so I personally
> do not classify it as "popular" just because it had a spike in tweets.
>
> Evaluate both frameworks and choose the one that fits your case better.
>
> You have not said what is it in Vert.x that appeals you. It's just the
> benchmark result ?
>
> Simon
> --
> http://cometd.org
> http://intalio.com
> http://bordet.blogspot.com
> ----
> Finally, no matter how good the architecture and design are,
> to deliver bug-free software with optimal performance and reliability,
> the implementation technique must be flawless.   Victoria Livschitz
>
_______________________________________________
jetty-users mailing list
[hidden email]
https://dev.eclipse.org/mailman/listinfo/jetty-users


_______________________________________________
jetty-users mailing list
[hidden email]
https://dev.eclipse.org/mailman/listinfo/jetty-users
Reply | Threaded
Open this post in threaded view
|

Re: [jetty-users] Apache HttpClient vs Java UrlConnection

Otis Gospodnetic
Joakim,

That's probably a good question from HttpClient mailing list.... I'd be curious about what info you can get there...
 
Otis
----
Performance Monitoring for Solr / ElasticSearch / HBase - http://sematext.com/spm 


From: Joakim Erdfelt <[hidden email]>
To: Otis Gospodnetic <[hidden email]>; JETTY user mailing list <[hidden email]>
Sent: Thursday, May 24, 2012 5:38 PM
Subject: Apache HttpClient vs Java UrlConnection

Is apache httpclient still viable?
Speaking from experience using both it and standard java UrlConnection on Android (key piece of info there), the standard java UrlConnection is faster in all aspects of http, from establishing the connection, handling the streams, authenticating, and even concurrent active connections than the Apache HttpClient on the same device.  No amount of tweaking of the apache httpclient could even get close to the standard naive implementation using Java UrlConnection.

Why is that?  Really, why?  Before this experience i was a huge fan of apache httpclient (i like the control I have over the http transactions), but now...
--
Joakim Erdfelt



On Thu, May 24, 2012 at 2:32 PM, Otis Gospodnetic <[hidden email]> wrote:
Thanks Simone,

I think Vert.x has more than just a spike of tweets, though :)

What I'm after is something that can handle a high number of concurrent connections from an HTTP client (e.g. Apache HttpClient) to an HTTP server (Jetty?).  You can see in my sig why I'm interested in this....

Thanks,
Otis 
----
Performance Monitoring for Solr / ElasticSearch / HBase - http://sematext.com/spm 




----- Original Message -----
> From: Simone Bordet <[hidden email]>
> To: Otis Gospodnetic <[hidden email]>; JETTY user mailing list <[hidden email]>
> Cc:
> Sent: Thursday, May 24, 2012 5:16 PM
> Subject: Re: [jetty-users] Vert.x-like functionality in Jetty?
>
> Hi,
>
> On Thu, May 24, 2012 at 8:59 PM, Otis Gospodnetic
> <[hidden email]> wrote:
>>  Hi,
>>
>>  Are you saying CometD provides the same scalability and concurrency Vert.x
>>  claims to provide?
>
> Look carefully at the Vert.x benchmark: they open 6 (six) connections
> and pipeline on each 2000 requests.
> How realistic is such traffic ?
>
> I am sure Vert.x 1.0 is a fine framework and all that, but I'd like to
> see a more realistic benchmark before expressing an opinion.
> That is what we tried to achieve with the CometD benchmark, which
> implements a chat application, with 1k, 5k 10k up to 200k connected
> users to a single server and different message rates.
>
>>  If CometD provides (and has been providing for years) the high scalability
>>  and concurrency support, what's all Vert.x all about?
>
> Ask them :)
> To me, it's about diversity.
> Why there exist more than one servlet container ?
>
>>  Is it the case that
>>  while CometD may provide the same stuff Vert.x does, CometD is not widely
>>  known or is at least not as popular? (if so, that can be critical for its
>>  future)
>
> Not sure what Vert.x provides yet (have not looked in details), but
> CometD provides authentication hooks, fine-grained access control,
> message acknowledgment and guaranteed server-to-client message
> delivery on short network failures, a fully extensible framework,
> transport independence and fallback, automatic reconnections, and I
> can continue for a while.
>
> I heard about Vert.x one month or less ago, actually, so I personally
> do not classify it as "popular" just because it had a spike in tweets.
>
> Evaluate both frameworks and choose the one that fits your case better.
>
> You have not said what is it in Vert.x that appeals you. It's just the
> benchmark result ?
>
> Simon
> --
> http://cometd.org
> http://intalio.com
> http://bordet.blogspot.com
> ----
> Finally, no matter how good the architecture and design are,
> to deliver bug-free software with optimal performance and reliability,
> the implementation technique must be flawless.   Victoria Livschitz
>
_______________________________________________
jetty-users mailing list
[hidden email]
https://dev.eclipse.org/mailman/listinfo/jetty-users




_______________________________________________
jetty-users mailing list
[hidden email]
https://dev.eclipse.org/mailman/listinfo/jetty-users
Reply | Threaded
Open this post in threaded view
|

Re: [jetty-users] Apache HttpClient vs Java UrlConnection

kim young ill
i read httpclient on android is a customized of the stock ahc, so it's rather old.
i think with ahc you have more control on what you're doing, you dont have to use httpclient directly but only httpcore.
there're also some usefull stuffs like cookie-parsing/handling, connection pool...

cheers


 

On Thu, May 24, 2012 at 11:40 PM, Otis Gospodnetic <[hidden email]> wrote:
Joakim,

That's probably a good question from HttpClient mailing list.... I'd be curious about what info you can get there...
 
Otis
----
Performance Monitoring for Solr / ElasticSearch / HBase - http://sematext.com/spm 


From: Joakim Erdfelt <[hidden email]>

To: Otis Gospodnetic <[hidden email]>; JETTY user mailing list <[hidden email]>
Sent: Thursday, May 24, 2012 5:38 PM
Subject: Apache HttpClient vs Java UrlConnection

Is apache httpclient still viable?
Speaking from experience using both it and standard java UrlConnection on Android (key piece of info there), the standard java UrlConnection is faster in all aspects of http, from establishing the connection, handling the streams, authenticating, and even concurrent active connections than the Apache HttpClient on the same device.  No amount of tweaking of the apache httpclient could even get close to the standard naive implementation using Java UrlConnection.

Why is that?  Really, why?  Before this experience i was a huge fan of apache httpclient (i like the control I have over the http transactions), but now...
--
Joakim Erdfelt



On Thu, May 24, 2012 at 2:32 PM, Otis Gospodnetic <[hidden email]> wrote:
Thanks Simone,

I think Vert.x has more than just a spike of tweets, though :)

What I'm after is something that can handle a high number of concurrent connections from an HTTP client (e.g. Apache HttpClient) to an HTTP server (Jetty?).  You can see in my sig why I'm interested in this....

Thanks,
Otis 
----
Performance Monitoring for Solr / ElasticSearch / HBase - http://sematext.com/spm 




----- Original Message -----
> From: Simone Bordet <[hidden email]>
> To: Otis Gospodnetic <[hidden email]>; JETTY user mailing list <[hidden email]>
> Cc:
> Sent: Thursday, May 24, 2012 5:16 PM
> Subject: Re: [jetty-users] Vert.x-like functionality in Jetty?
>
> Hi,
>
> On Thu, May 24, 2012 at 8:59 PM, Otis Gospodnetic
> <[hidden email]> wrote:
>>  Hi,
>>
>>  Are you saying CometD provides the same scalability and concurrency Vert.x
>>  claims to provide?
>
> Look carefully at the Vert.x benchmark: they open 6 (six) connections
> and pipeline on each 2000 requests.
> How realistic is such traffic ?
>
> I am sure Vert.x 1.0 is a fine framework and all that, but I'd like to
> see a more realistic benchmark before expressing an opinion.
> That is what we tried to achieve with the CometD benchmark, which
> implements a chat application, with 1k, 5k 10k up to 200k connected
> users to a single server and different message rates.
>
>>  If CometD provides (and has been providing for years) the high scalability
>>  and concurrency support, what's all Vert.x all about?
>
> Ask them :)
> To me, it's about diversity.
> Why there exist more than one servlet container ?
>
>>  Is it the case that
>>  while CometD may provide the same stuff Vert.x does, CometD is not widely
>>  known or is at least not as popular? (if so, that can be critical for its
>>  future)
>
> Not sure what Vert.x provides yet (have not looked in details), but
> CometD provides authentication hooks, fine-grained access control,
> message acknowledgment and guaranteed server-to-client message
> delivery on short network failures, a fully extensible framework,
> transport independence and fallback, automatic reconnections, and I
> can continue for a while.
>
> I heard about Vert.x one month or less ago, actually, so I personally
> do not classify it as "popular" just because it had a spike in tweets.
>
> Evaluate both frameworks and choose the one that fits your case better.
>
> You have not said what is it in Vert.x that appeals you. It's just the
> benchmark result ?
>
> Simon
> --
> http://cometd.org
> http://intalio.com
> http://bordet.blogspot.com
> ----
> Finally, no matter how good the architecture and design are,
> to deliver bug-free software with optimal performance and reliability,
> the implementation technique must be flawless.   Victoria Livschitz
>
_______________________________________________
jetty-users mailing list
[hidden email]
https://dev.eclipse.org/mailman/listinfo/jetty-users




_______________________________________________
jetty-users mailing list
[hidden email]
https://dev.eclipse.org/mailman/listinfo/jetty-users



_______________________________________________
jetty-users mailing list
[hidden email]
https://dev.eclipse.org/mailman/listinfo/jetty-users