Hi,

On Sun, Jan 14, 2018 at 10:29 PM, Michael Kilburn <crusader.mike_at_gmail.com>
wrote:

> On Sun, Jan 14, 2018 at 4:02 PM, Daniel Stenberg <daniel_at_haxx.se> 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
Received on 2018-01-16