Re: unexpected code 35 (if tcp listen backlog is full)
Date: Tue, 16 Jan 2018 01:33:25 -0600
On Tue, Jan 16, 2018 at 1:09 AM, Daniel Stenberg <daniel_at_haxx.se> wrote:
> On Mon, 15 Jan 2018, Michael Kilburn wrote:
> 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).
> I'm sorry but I don't understand what you're trying to achieve nor how you
> do it.
Hmm... did I accidentally delete a portion of message? It is definitely
hard on eyes. My apologies :)
I've created a cache (an instance of std::stack<CURL*>) protected by mutex.
Each thread (in order to send data out) tries to get a handle from cache
first (and if not -- creates it using related libcurl function). Once
thread is done (with sending data) -- handle gets pushed into the cache.
curl_easy_setopt(CURLOPT_WRITEFUNCTION, ...) // func discards incoming
> I trust this callback return the correct value still? Otherwise it'll
> probably cause the connection to get closed.
Yes, everything works as intended. Only problem is that (judging by accept
queue size) tcp connections and (judging by high CPU usage) TLS sessions
don't get reused.
> In the easy interface (that you are using when _easy_perform is called),
> the connection cache is held in the easy handle so unless you share the
> connection cache between handles you must make sure to re-use a handle that
> was previously used to communicate with the same host as otherwise it won't
> have the previous connection in its cache...
all threads talk to the same server (same url). I expected that if I reuse
easy handles between my "post_data()" invocations -- it'll lead to reuse of
underlying tcp connection (and TLS sessions).
> Maybe one of these options prevent tcp connection (and related TLS session
>> key) from being reused?
> Connections can also get closed by the server's decisions.
You might have solved my problem right here. I am testing all this
using BaseHTTPServer and ssl python modules -- it is quite likely
BaseHTTPServer closes connection after each POST.
I bet ssl module doesn't support TLS session caching too. Good thing in
prod environment I have a real web server. Hmm... need to figure out how to
ensure both caching mechanisms are ON.
Thank you for help, Daniel.
Received on 2018-01-16