On Fri, Nov 10, 2017 at 10:00 PM, Daniel Stenberg <[email protected]> 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. > > -- > > / daniel.haxx.se ------------------------------------------------------------------- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
