Hi, On Sun, Jan 14, 2018 at 10:29 PM, Michael Kilburn <[email protected]> wrote:
> On Sun, Jan 14, 2018 at 4:02 PM, Daniel Stenberg <[email protected]> wrote: >> >> libcurl will handle that for you transparently. You should always be able >> to re-use an existing easy handle for subsequent requests. Also, if you use >> the multi interface, the connection pool is actually owned/held by the >> multi handle so then re-using easy handles isn't that important. > > > It doesn't seem to work for me -- I've crated a shared cache of easy handles, after thread is done sending data, it returns handle (CURL*) into cache (actually, stack). But on server side accept queue size is always 20-30 while client is sending data (and performance has barely changed). After handle is pulled from cache it undergoes these operations (before being put back into cache): curl_easy_setopt(CURLOPT_URL, ...) curl_easy_setopt(CURLOPT_NOSIGNAL, 1l) curl_easy_setopt(CURLOPT_SSL_OPTIONS, CURLSSLOPT_NO_REVOKE) curl_easy_setopt(CURLOPT_HTTPHEADER, ...) // only Content-Type, User-Agent, Copyright, Expect, Authorization gets set here curl_easy_setopt(CURLOPT_POSTFIELDSIZE, ...) curl_easy_setopt(CURLOPT_POSTFIELDS, ...) curl_easy_setopt(CURLOPT_WRITEFUNCTION, ...) // func discards incoming data curl_easy_perform() Maybe one of these options prevent tcp connection (and related TLS session key) from being reused? I'll try to get some trace info tomorrow, but any idea would be appreciated. -- Regards, Michael.
------------------------------------------------------------------- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
