I have updated my original event server spike, on gitlab. The url is : https://gitlab.com/druppy/spikes/-/tree/master/cpp/ev_server
It should be compilable on any linux / bsd box, using cmake. It is a simple server that answers pong on all requests, if I test it using : ab -c 500 -n 30000 http://localhost/ping I get from 0 - 200 length errors. I have keeps the logging to make things more easy to follow. Please let me know if you find anything interesting. /BL Den søn. 16. feb. 2020 kl. 11.37 skrev Bo Lorentsen <[email protected]>: > On 2/16/20 9:08 AM, Bernd Petrovitsch wrote: > > Hi all! > Thanks for taking you time to look into this, I really appreciate it. > >> I have been using libev for a while in a project at work (currently > >> 4.25), with success for quite a while, and I have now expanded the usage > >> in our service to also include the accepting of new connection (used > >> blocking accept before). > > So I infer that you use now non-blocking sockets (both for > > accept() and read()) > You infer correctly :-) > >> I have a callback that gets called on every accept (where I loop on > >> EAGAIN to empty the backlog), and for each new socket I make an protocol > >> structure (class really). I read from the socket, and sometime it gives > >> me EAGAIN and sometimes i get data, all this is working as it should, > >> but !!! > >> > >> I did like to try our the server by using apache benchmark, and this > >> worked really nice in the beginning (both localhost, and real lan), but > >> when i go up to about 20k connections, and concurrency of 500 i gets a > >> few sockets that I can't read from, at all. recv returns -1 and EAGAIN, > >> but it never gets any data. > > -1 + EAGAIN neans that there is currently nothing to read() > > or accept() ATM. So far perfectly normal. > Yeps, and it works really nice this far. > > Do select()/poll() reprot before that there should be > > somethign to read()/accept()? > As I am using libev with a EV_READ on listen socket and the same for the > newly created socket, I guess libev default init "Do select()/poll() > reprot" (I am using 4.25 on debian stable, that packaged version). > >> I order to check for any missing select errors (just a wild guess) I > > select() also returns -1 (and sets errno) on errors ... > > Yeps, I try to handle ALL error cases, on every step of the way, but the > problem i have is not an error in any way, as "recv" returns EAGAIN as > expected, but no data ever occur on the socket. In short i make a recv > get EAGAIN, and no more EV_READ happens, like the socket is frozen. > > I have even tested for double close, and extended the backlog just in > case, but non gave any useful results. > > > > >> also setup a reread timer when recv returns -1 (and EAGAIN) in order to > >> try read again, even on missing read event, but data still never > arrives. > >> > >> Are there something I am not aware of, or have others seen something > >> like this ? I really appreciate any comments, I have tried google and > >> found nothing useful on this specific subject. > > I do not see any real bug up here anywhere. > I am both happy and sad at once to hear this :-) > > Are you sure that each (logical) connection (in your > > program) has a different file descriptor? > > For each incoming connection i allocate a new "protocol" class, that > takes ownership of the socket until the protocol is destroyed after > proper termination. It is just a plain http server, so it is simple > accept -> make protocol on socket -> recv header .... > > Note that accept does not return the same socket before it have been > closed, and the socket is closed on my protocol destruction. Had i have > double close i would have a bad connection, but it is perfectly fin, but > has no read data in rare ocasions ! > > I think I will try to build a small spike of this server, so there is > some code to discus, I will return with this later when I have time to > compile such. > > Again, thanks for taking the time to understand my problem ! > > Regards > > /BL > >
_______________________________________________ libev mailing list [email protected] http://lists.schmorp.de/mailman/listinfo/libev
