curl / Mailing Lists / curl-library / Single Mail

curl-library

Re: epoll() request drop issue

From: Daniel Stenberg <daniel_at_haxx.se>
Date: Sat, 29 Jul 2017 16:34:17 +0200 (CEST)

On Tue, 25 Jul 2017, Tushar Pathare via curl-library wrote:

> I have observed that epoll_wait() function alway's waiting for given timeout
> for the first iteration (no any event get ready) and in next successive
> iteration events are available. My endpoint return response within 50ms, so
> why epoll_wait() not return me any event within specified timeout (currently
> its 200ms).

First, you ignore the timeout time given to you by libcurl when it calls your
timeout callback. The timeout libcurl gives you should be used so you won't
wait too long when there's no action.

If you do get a response on a socket and epoll() doesn't tell you about it, I
don't know why that is so. epoll's sole purpose is to monitor the given
sockets and inform your application when one of them had "activity".

> As we already given a call to *curl_multi_socket_action(multi,
> CURL_SOCKET_TIMEOUT, 0, &running_handles), *why data transfer is not
> started and why epoll_wait() is waiting for the complete timeout without
> returning any event ready. I'm missing any call before epoll_wait() ?

That call to curl_multi_socket_action() will initiate some transfers, sure,
and call your callbacks. You should then call it again when the timeout
expires or when one of the sockets show actitivity.

> I have attached my implementation.

... which ignores the timeout callback. I'd call that a major flaw.

I personally never work against epoll directly (I use event libraries to make
the code portable for more platforms) so I can't tell whether epoll is used
correctly or not.

One detail though: you only support readable *OR* writable events when reading
the event from epoll_wait(), not combined readable+writable, which looks like
a bug. The 'events' firled there is a bitmask, not simple values.

>> What exactly is a "request drop" according to you?

> Let's say I have configured two thread and each thread making 50 parallel
> requests using curl multi handle, so the total number of expected request
> hit will be 100. But I'm getting only 85 to 90 request hit on my request
> endpoint. So the delta between expected hits and actual hit I'm considering
> as request drops. Here now it is between 10-15.

So decrease the amount to just 2 or 3 or whatever and figure out exactly where
these "drops" happen. There should be *no* such drops. Zero. Then add more and
see that they work.

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html
Received on 2017-07-29