Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Responses never terminate (ab dies with timeout error) (OS X) #16

Open
joshgoebel opened this issue Oct 15, 2018 · 8 comments
Open

Responses never terminate (ab dies with timeout error) (OS X) #16

joshgoebel opened this issue Oct 15, 2018 · 8 comments
Labels

Comments

@joshgoebel
Copy link

Using latest jester and Apache bench and for some reason it thinks the requests timeout. Perhaps we're not closing a socket properly or something? It's 100% reproducible here and only with httpbeast. asynchttpserver does not have the same issue.

nim c -d:release -r tests/example
...

INFO Jester is making jokes at http://0.0.0.0:5000
Starting 1 threads
ab -r -n 1000 -c 1000 http://0.0.0.0:5000/
This is ApacheBench, Version 2.3 <$Revision: 1826891 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 0.0.0.0 (be patient)
apr_pollset_poll: The timeout specified has expired (70007)

Seems to work fine in browser and with curl. AB is receiving the responses (if I used -v2), but obviously something else is off.

Thoughts?

@joshgoebel joshgoebel changed the title Responses never terminate (OS X) Responses never terminate (ab dies with timeout error) (OS X) Oct 15, 2018
@joshgoebel
Copy link
Author

Pretty sure this is because we don't yet support close=0 or keep-alive=0.

@dom96
Copy link
Owner

dom96 commented Oct 15, 2018

Hrm, interesting. Not sure what the problem could be, I'd need to look into how apache bench creates requests.

@joshgoebel
Copy link
Author

        if data.sendQueue.len == data.bytesSent:
          data.bytesSent = 0
          data.sendQueue.setLen(0)
          data.data.setLen(0)

          # selector.unregister(fd)
          # fd.SocketHandle.close()
          selector.updateHandle(fd.SocketHandle,
                                {Event.Read})

Adding the two commented lines fixed it for me... but of course (if this is the proper place to add them) they would need to be dependent on the Close/Keep-Alive/ and HTTP version. You can see how it's done in asynchttpserver if you want a reference.

ab is using HTTP/1.0 (though it doesn't seem to mind the 1.1 being returned) which by default expects keep-alive to be off and the connection to be terminated by the server - which we aren't doing.

@2vg
Copy link

2vg commented Oct 25, 2018

@yyyc514 You can use wrk instead of ab.
Although ab is a single thread and old tool, but wrk runs in multithreading.
If you want to use wrk with single thread, simply specify -t 1 with the command line option.
wrk -t 1 http://localhost:8080
Techempower, a famous benchmark, also uses wrk to measure it.

@joshgoebel
Copy link
Author

Yeah I've been using wrk, but still think httpbeast isn't doing the correct connection handling here.

@dom96 dom96 added the bug label Jun 11, 2022
@kolesar-andras
Copy link

Same problem here.

@treeform
Copy link

I also ran into this.

@treeform
Copy link

I tried this work around by adding req.client.close() to end of requests, but I get this error after some requests:

Error: unhandled exception: ioselectors_epoll.nim(147, 11) `s.fds[fdi].ident == InvalidIdent` Descriptor 118 already registered [AssertionDefect]```

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants