curl / Mailing Lists / curl-library / Single Mail

curl-library

Re: Too many connections in TIME_WAIT state

From: Daniel Stenberg via curl-library <curl-library_at_cool.haxx.se>
Date: Sun, 20 Jan 2019 17:41:10 +0100 (CET)

On Sun, 20 Jan 2019, Vipin P R wrote:

> I have a small clarification on the use of the libcurl library.

I'm sorry but this really is not "a small clarification" you're asking for.
Your email is full of questions about very specific behaviors that your
application seems to experience, but it almost completely lacks details on
what your application does and how it uses libcurl. This makes it almost
impossible to answer any of the questions you have in here.

> In my project, i am trying to send 3 requests using the multi interface and
> polling via libuv based on multi-uv.c When we are comparing this w.r.t to
> Apache bench, which I am using as my comparison tool, I am seeing that with
> libcurl, there are so many connections in TIME_WAIT state.

I don't understand the setup. You're doing three requests. In parallel or
serially? And where does the "many connections in TIME_WAIT state" enter? With
three requests, surely that's three connections as max?

Your comparison with Apache bench makes me suspect you're looping these
requests, are you?

> One oddity I can see is that in Apache bench, they wait for the FIN from
> the server, and then close the connection. However in case of libcurl, we
> are sending the FIN.

That would depend entirely on libcurl options and how the server responds do
the libcurl requests.

> Is there any way to tweak this behaviour so that we don't initiate the FIN,
> instead wait for the server to do it.

The normal behavior is for libcurl to maintain connections as far as possible
and never close them. You'd need to explain with more details how you use
libcurl. Probably also what libcurl version and on what platform.

> Another issue I request you help with understanding is that the CPU and RAM
> utilization of Apache Bench for the same type of GET requests is pretty low
> compared to my tool which internally uses libcurl to do the same thing.

Again we don't know what you do in your program so we can't tell why that uses
more RAM. I don't think libcurl itself ever uses much memory in basically any
case, but I might forget some corner case right now.

> With concurrency : 10 <concurrency = num_multi handles (each has 1 request)

Concurrency how? You said you did three requests.

> - My tool sends a new SYN before the first connection is complete

... and you haven't explained what it does nor what it receives (HTTP wise) so
we can't say if that's expected or not.

My suggestion: write up a totally separate example source code that does
something similar to what your application does, but as small and simple as
possible and that can reproduce the problem or the strange scenario that
you're seeing. Then we can discuss libcurl usage, hunting for possible bugs
and other people might be able to reproduce etc.

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html
Received on 2019-01-20