curl / Mailing Lists / curl-library / Single Mail

curl-library

Re: Too many connections in TIME_WAIT state

From: Vipin P R via curl-library <curl-library_at_cool.haxx.se>
Date: Mon, 21 Jan 2019 11:30:36 +0530

Hi,
   Thanks for the info.
   I have tried with curl to the same URL. I can see that the client is the
one initiating the FIN. In case of AB, the client always waits for the
server to initiate the FIN. Is there any way to change this behaviour in
libcurl or setsockopt().
Sincerely,
Vipin

On Sun, Jan 20, 2019 at 10:11 PM Daniel Stenberg <daniel_at_haxx.se> wrote:

> 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-21