[erlang-questions] HttpC options

[Ingela Andin]

Hi!

I will try to clear it up for you.

There is a consept called persistent conections and another one called
pipelining that uses persistent connections in a different manner.
So in both cases you reuse a connection to a server to send subsequent
requests.  You can not use both concepts at once you will have to
choose.

When using persistent connections without pipelining a request will be
sent and the client waits for the reply and then the next request is
sent and again the client waits for the reply and so on.

When using pipelining you will send the next requests imediatly before
receiving the answer to the previous request. The server will awnser
the request in the same order that they where sent. If the connection
is broken outstanding request will be automatically resent on a new
connection.

Also note from the documentation

"If possible the client will keep its connections alive and use
persistent connections with or without pipeline depending on
configuration and current circumstances. The HTTP/1.1 specification
does not provide a guideline for how many requests would be ideal to
be sent on a persistent connection, this very much depends on the
application. Note that a very long queue of requests may cause a user
perceived delay as earlier requests may take a long time to
complete. The HTTP/1.1 specification does suggest a limit of 2
persistent connections per server, which is the default value of the
max_sessions option."

Regards Ingela Erlang/OTP team - Ericsson AB



2012/5/30, Ingela Andin <ingela.andin@REDACTED>:
> Hi!
>
> I will try to clear it up for you.
>
> There is a consept called persistent conections and another one called
> pipelining that uses persistent connections in a different manner.
> So in both cases you reuse a connection to a server to send subsequent
> requests.  You can not use both concepts at once you will have to
> choose.
>
> When using persistent connections without pipelining a request will be
> sent and the client waits for the reply and then the next request is
> sent and again the client waits for the reply and so on.
>
> When using pipelining you will send the next requests imediatly before
> receiving the answer to the previous request. The server will awnser
> the request in the same order that they where sent. If the connection
> is broken outstanding request will be automatically resent on a new
> connection.
>
> Also note from the documentation
>
> "If possible the client will keep its connections alive and use
> persistent connections with or without pipeline depending on
> configuration and current circumstances. The HTTP/1.1 specification
> does not provide a guideline for how many requests would be ideal to
> be sent on a persistent connection, this very much depends on the
> application. Note that a very long queue of requests may cause a user
> perceived delay as earlier requests may take a long time to
> complete. The HTTP/1.1 specification does suggest a limit of 2
> persistent connections per server, which is the default value of the
> max_sessions option."
>
> Regards Ingela Erlang/OTP team - Ericsson AB
>
>
> 2012/5/29, Avinash Dhumane <avinash@REDACTED>:
>> I am not able to sense the difference between "max_keep_alive_length" and
>> "max_pipeline_length" options ("httpc" module) in pipelining scenario
>> (turned on by setting pipeline_timeout to timer:seconds(60)).
>>
>> Documentation says:
>> max_keep_alive_length = maximum number of outstanding requests on the
>> _same_ connection to a host
>> max_pipeline_length = maximum number of outstanding requests on a
>> _pipelined_ connection to a host
>>
>> Questions are:
>> 1) Can both these options co-exist in pipelining scenario? If so, what
>> aspects of requests submissions would they affect?
>> 2) In "without pipelining" scenario, what is the meaning of keeping more
>> than one outstanding request on the _same_ connection, i.e.
>> max_keep_alive_length option? Can it really be done? If so, how different
>> it is from pipelining?
>>
>> I am quite confused! :-)
>>
>> Please.
>>
>> Thanks.
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>