[jetty-dev] Information regarding Jetty HTTP Client properties

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[jetty-dev] Information regarding Jetty HTTP Client properties

Neha Munjal
Hi,

We are working with Jetty 9.4.3.v20170317 distribution and using the low level HttpClient  API to create Http2Client objects to be able to do HTTP/2 communication both synchronously and asynchronously.

Since, we could not find much information for all the properties in the API documentation, I would like to clarify the usage of following 2 properties that can be set on the client object:

1. IdleTimeout: How does this property behave? In case a connection becomes idle, i.e no data exchange from either side, is this connection just added back to the list of idle connection in the underlying connection pool? We have a use case wherein we would just create 1 connection and stream requests, so we would like to understand if a connection became idle and say, we have a new incoming request to make HTTP communication, would we use this connection and activate it so that it could be used for the exchange? Also if this property is not explicitly configured, does it assume some default value?

2. AddressResolutionTimeout: What is the significance to set this timeout property? We do set the connection timeout. If addressResolutionTimeout is not explicitly set, does this property default to connection timeout?

Thanks
Neha

_______________________________________________
jetty-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [jetty-dev] Information regarding Jetty HTTP Client properties

Simone Bordet-3
Hi,

On Wed, Apr 19, 2017 at 7:13 PM, Neha Munjal <[hidden email]> wrote:
> Hi,
>
> We are working with Jetty 9.4.3.v20170317 distribution and using the low
> level HttpClient  API to create Http2Client objects to be able to do HTTP/2
> communication both synchronously and asynchronously.

Given the properties below, you are using the *high* level HttpClient.
The low level one does not have, for example, the
"addressResolutionTimeout" property.

> Since, we could not find much information for all the properties in the API
> documentation, I would like to clarify the usage of following 2 properties
> that can be set on the client object:
>
> 1. IdleTimeout: How does this property behave? In case a connection becomes
> idle, i.e no data exchange from either side, is this connection just added
> back to the list of idle connection in the underlying connection pool?

No, the connection is closed.

> We have a use case wherein we would just create 1 connection and stream
> requests, so we would like to understand if a connection became idle and
> say, we have a new incoming request to make HTTP communication, would we use
> this connection and activate it so that it could be used for the exchange?

After the idle timeout, if a new request comes in it will trigger the
creation of a new connection.

> Also if this property is not explicitly configured, does it assume some
> default value?

Yes.

> 2. AddressResolutionTimeout: What is the significance to set this timeout
> property? We do set the connection timeout. If addressResolutionTimeout is
> not explicitly set, does this property default to connection timeout?

This is the timeout for DNS resolution, that is to resolve the host
name in string form to an IP address.
Once the host name is resolved, it can be used to open a connection,
where the connectionTimeout applies.

Therefore, the addressResolutionTimeout and the connectTimeout are not
related (much).

--
Simone Bordet
----
http://cometd.org
http://webtide.com
Developer advice, training, services and support
from the Jetty & CometD experts.
_______________________________________________
jetty-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [jetty-dev] Information regarding Jetty HTTP Client properties

Neha Munjal
Hi Simone,

Thanks for the inputs.
Here are some follow up questions:


2. AddressResolutionTimeout: What is the significance to set this timeout
> property? We do set the connection timeout. If addressResolutionTimeout is
> not explicitly set, does this property default to connection timeout?

This is the timeout for DNS resolution, that is to resolve the host
name in string form to an IP address.
Once the host name is resolved, it can be used to open a connection,
where the connectionTimeout applies.

Therefore, the addressResolutionTimeout and the connectTimeout are not
related (much).

> In that case, the purpose of setting this property would help in identifying a request
that carries a bad host name before even trying to establish a connection and result in exceptions like UnknownHostException.
Can you please clarify this?

Also, we have a use case wherein we have a requirement to send approximately 10,000 HTTP/2 requests per second to a target end point.
We plan to configure the client object with 1 connection and a high value of the number of queued requests.
(Also, as mentioned in the Java Docs, it is advised to set the number of connections property to a maximum of 2.)
We do have a throttling mechanism on our end to send approx to trigger 10,000 requests from the client end.
Is there a correlation that we could use to set the number of queued requests with 1 connection with the throughput we want to achieve to be able to send these requests successfully without running into request rejection failures or in such a scenario, can we configure the client object with a higher number of connection.
Please let me know your recommendation.

Thanks
Neha





On Wed, Apr 19, 2017 at 10:41 AM, Simone Bordet <[hidden email]> wrote:
Hi,

On Wed, Apr 19, 2017 at 7:13 PM, Neha Munjal <[hidden email]> wrote:
> Hi,
>
> We are working with Jetty 9.4.3.v20170317 distribution and using the low
> level HttpClient  API to create Http2Client objects to be able to do HTTP/2
> communication both synchronously and asynchronously.

Given the properties below, you are using the *high* level HttpClient.
The low level one does not have, for example, the
"addressResolutionTimeout" property.

> Since, we could not find much information for all the properties in the API
> documentation, I would like to clarify the usage of following 2 properties
> that can be set on the client object:
>
> 1. IdleTimeout: How does this property behave? In case a connection becomes
> idle, i.e no data exchange from either side, is this connection just added
> back to the list of idle connection in the underlying connection pool?

No, the connection is closed.

> We have a use case wherein we would just create 1 connection and stream
> requests, so we would like to understand if a connection became idle and
> say, we have a new incoming request to make HTTP communication, would we use
> this connection and activate it so that it could be used for the exchange?

After the idle timeout, if a new request comes in it will trigger the
creation of a new connection.

> Also if this property is not explicitly configured, does it assume some
> default value?

Yes.

> 2. AddressResolutionTimeout: What is the significance to set this timeout
> property? We do set the connection timeout. If addressResolutionTimeout is
> not explicitly set, does this property default to connection timeout?

This is the timeout for DNS resolution, that is to resolve the host
name in string form to an IP address.
Once the host name is resolved, it can be used to open a connection,
where the connectionTimeout applies.

Therefore, the addressResolutionTimeout and the connectTimeout are not
related (much).

--
Simone Bordet
----
http://cometd.org
http://webtide.com
Developer advice, training, services and support
from the Jetty & CometD experts.
_______________________________________________
jetty-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-dev


_______________________________________________
jetty-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [jetty-dev] Information regarding Jetty HTTP Client properties

Simone Bordet-3
Hi,

On Wed, Apr 19, 2017 at 9:06 PM, Neha Munjal <[hidden email]> wrote:
>> In that case, the purpose of setting this property would help in
>> identifying a request
> that carries a bad host name before even trying to establish a connection
> and result in exceptions like UnknownHostException.
> Can you please clarify this?

It is a DNS timeout. I would not give it more meaning than what it actually is.
Whether it is caused by a bad host name, a bad network, a bad ISP,
etc. is not really relevant.

> Also, we have a use case wherein we have a requirement to send approximately
> 10,000 HTTP/2 requests per second to a target end point.
> We plan to configure the client object with 1 connection and a high value of
> the number of queued requests.

I don't think this is going to fly.
For 10k requests/s you probably need more than 1 connection to the
server, otherwise your requests are going to spend a lot of time
queued.

> (Also, as mentioned in the Java Docs, it is advised to set the number of
> connections property to a maximum of 2.)

Where is this ?

> We do have a throttling mechanism on our end to send approx to trigger
> 10,000 requests from the client end.
> Is there a correlation that we could use to set the number of queued
> requests with 1 connection with the throughput we want to achieve to be able
> to send these requests successfully without running into request rejection
> failures or in such a scenario, can we configure the client object with a
> higher number of connection.
> Please let me know your recommendation.

This is really complicate matter, it depends on a lot of factors,
among which network latency, request/response sizes, etc.

I recommend that you look into our load generator, since typically the
client is the one that is subject to the greater stress and cannot
keep up with the server.
One single client generating 10k requests/s in steady state, I think I
have still to see it; you probably will need more than 1.
https://github.com/jetty-project/jetty-load-generator

If you have this hard requirement of 10k requests/s, I suggest you
contact Webtide for commercial support, as we have done this kind of
things in the past for other customers.
https://webtide.com/

--
Simone Bordet
----
http://cometd.org
http://webtide.com
Developer advice, training, services and support
from the Jetty & CometD experts.
_______________________________________________
jetty-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [jetty-dev] Information regarding Jetty HTTP Client properties

Neha Munjal
Thanks for the details Simone.


It also mentions that this needs to be set to a higher value in case we need to load tests, but our use case is a PROD use case, and not a test use case, so was confused if the high setting value would lead to issues/instability.
We would anyways, try setting a higher value and do some tests to confirm if this scales or not.

Regards
Neha

On Thu, Apr 20, 2017 at 2:56 AM, Simone Bordet <[hidden email]> wrote:
Hi,

On Wed, Apr 19, 2017 at 9:06 PM, Neha Munjal <[hidden email]> wrote:
>> In that case, the purpose of setting this property would help in
>> identifying a request
> that carries a bad host name before even trying to establish a connection
> and result in exceptions like UnknownHostException.
> Can you please clarify this?

It is a DNS timeout. I would not give it more meaning than what it actually is.
Whether it is caused by a bad host name, a bad network, a bad ISP,
etc. is not really relevant.

> Also, we have a use case wherein we have a requirement to send approximately
> 10,000 HTTP/2 requests per second to a target end point.
> We plan to configure the client object with 1 connection and a high value of
> the number of queued requests.

I don't think this is going to fly.
For 10k requests/s you probably need more than 1 connection to the
server, otherwise your requests are going to spend a lot of time
queued.

> (Also, as mentioned in the Java Docs, it is advised to set the number of
> connections property to a maximum of 2.)

Where is this ?

> We do have a throttling mechanism on our end to send approx to trigger
> 10,000 requests from the client end.
> Is there a correlation that we could use to set the number of queued
> requests with 1 connection with the throughput we want to achieve to be able
> to send these requests successfully without running into request rejection
> failures or in such a scenario, can we configure the client object with a
> higher number of connection.
> Please let me know your recommendation.

This is really complicate matter, it depends on a lot of factors,
among which network latency, request/response sizes, etc.

I recommend that you look into our load generator, since typically the
client is the one that is subject to the greater stress and cannot
keep up with the server.
One single client generating 10k requests/s in steady state, I think I
have still to see it; you probably will need more than 1.
https://github.com/jetty-project/jetty-load-generator

If you have this hard requirement of 10k requests/s, I suggest you
contact Webtide for commercial support, as we have done this kind of
things in the past for other customers.
https://webtide.com/

--
Simone Bordet
----
http://cometd.org
http://webtide.com
Developer advice, training, services and support
from the Jetty & CometD experts.
_______________________________________________
jetty-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-dev


_______________________________________________
jetty-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [jetty-dev] Information regarding Jetty HTTP Client properties

Simone Bordet-3
Hi,

On Thu, Apr 20, 2017 at 8:47 PM, Neha Munjal <[hidden email]> wrote:
>>> (Also, as mentioned in the Java Docs, it is advised to set the number of
>>> connections property to a maximum of 2.)
>>
>>Where is this ?
>
> The Java Doc that mentions this is available @
> http://download.eclipse.org/jetty/stable-9/apidocs/org/eclipse/jetty/client/HttpClient.html#setMaxConnectionsPerDestination--

The Javadoc says what RFC 2616 was recommending, not what it is
advised to do. And BTW that RFC is now 20 years old, so it should
probably be removed from the Javadoc.
What it is advised to do depends on your use case.

> It also mentions that this needs to be set to a higher value in case we need
> to load tests, but our use case is a PROD use case, and not a test use case,
> so was confused if the high setting value would lead to issues/instability.

There should be no issues.

> We would anyways, try setting a higher value and do some tests to confirm if
> this scales or not.

Please do.
HttpClient defaults MaxConnectionsPerDestination to 64, but feel free
to experiment with different values (smaller or larger).

--
Simone Bordet
----
http://cometd.org
http://webtide.com
Developer advice, training, services and support
from the Jetty & CometD experts.
_______________________________________________
jetty-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [jetty-dev] Information regarding Jetty HTTP Client properties

Neha Munjal
Thanks for all the clarifications Simone.
We will work it and experiment with different values to see how it goes!

Thanks
Neha

On Thu, Apr 20, 2017 at 3:41 PM, Simone Bordet <[hidden email]> wrote:
Hi,

On Thu, Apr 20, 2017 at 8:47 PM, Neha Munjal <[hidden email]> wrote:
>>> (Also, as mentioned in the Java Docs, it is advised to set the number of
>>> connections property to a maximum of 2.)
>>
>>Where is this ?
>
> The Java Doc that mentions this is available @
> http://download.eclipse.org/jetty/stable-9/apidocs/org/eclipse/jetty/client/HttpClient.html#setMaxConnectionsPerDestination--

The Javadoc says what RFC 2616 was recommending, not what it is
advised to do. And BTW that RFC is now 20 years old, so it should
probably be removed from the Javadoc.
What it is advised to do depends on your use case.

> It also mentions that this needs to be set to a higher value in case we need
> to load tests, but our use case is a PROD use case, and not a test use case,
> so was confused if the high setting value would lead to issues/instability.

There should be no issues.

> We would anyways, try setting a higher value and do some tests to confirm if
> this scales or not.

Please do.
HttpClient defaults MaxConnectionsPerDestination to 64, but feel free
to experiment with different values (smaller or larger).

--
Simone Bordet
----
http://cometd.org
http://webtide.com
Developer advice, training, services and support
from the Jetty & CometD experts.
_______________________________________________
jetty-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-dev


_______________________________________________
jetty-dev mailing list
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-dev
Loading...