curl / Mailing Lists / curl-library / Single Mail


Re: Pipelining of POST requests

From: Sunil Sayyaparaju via curl-library <>
Date: Tue, 14 Nov 2017 15:20:15 +0530

On Fri, Nov 10, 2017 at 10:00 PM, Daniel Stenberg <> wrote:
> On Thu, 9 Nov 2017, Sunil Sayyaparaju via curl-library wrote:
>> I am doing POST requests which are idempotent. I want to exploit the
>> benefit of pipelining as I will be sending a sequence of post msgs almost on
>> continuous basis. This will be over WAN link. So, pipelining will be ideal
>> for me.
> I would recommend going HTTP/2 instead if you can. HTTP/2 is a better
> pipelining from spec to implementation. And since it is more widely used by
> curl users, it probably also has less bugs than the pipelining
> implementation.

I need to support HTTP1.1 as well and in the best way possible.
I am developing support for HTTP2 also in parallel. I am struggling
a bit to tune performance there but that's an orthogonal discussion.

>> I will be happy to know in advance If I need to worry about any other
>> issues the libcurl may throw at me because of my change. Are non-idempotent
>> POST requests the only reason why they are not allowed to pipeline ? Or are
>> there any libcurl level issue that I need to be aware of ?
> I'm mostly just worried that pipelning in curl isn't as rock solid as many
> other areas are, simply due to it being a very rarely used feature.

I could see that its not optimal at present. For e.g CPU is spending
a lot of time in Curl_removeHandleFromPipeline() when there are
many responses that need to be processed. This function is walking
a linked list linearly. I am working around this by having more
multi-handles so that inflight requests per multi-handle are less.

As long as performance is the only issue, I guess I can work around
few of them or even improve them. I am worried about hitting design
issues that may haunt me as I am breaking philosophy here.

> --
> /
Received on 2017-11-14