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

evaluate and use fasthttp #6

Open
missedone opened this issue Feb 28, 2016 · 8 comments
Open

evaluate and use fasthttp #6

missedone opened this issue Feb 28, 2016 · 8 comments
Assignees

Comments

@missedone
Copy link
Collaborator

i saw this https://github.com/rakyll/boom/issues/94, we probably can evaluate it and use it if it really promise.

@eriklupander
Copy link
Owner

Sounds great. Assigned the issue to you if you want to give it a shot.

HTTP performance have been quite good so far, on my laptop (OS X) I usually run out of file handles before the CPU usage goes above 100% on a single core. But having less CPU usage due to HTTP implementation overhead sounds good.

Regarding memory use, I've seen pretty consistent behaviour where Gotling uses about 8 kb (each goroutine) x number of concurrent "users".

@missedone
Copy link
Collaborator Author

sure, will have a try later

@missedone
Copy link
Collaborator Author

i just pushed the initial implementation with fasthttp on feature/fasthttp branch.
for now, only GET is supported, i did a quick test, and found that there is performance degradation with fasthttp compared to stdlib net/http.
will dig deeper later to understand why.

below is an example, you can uncomment the client: fasthttp line to use fasthttp, by default it's using net/http:

---
iterations: 10
users: 10
rampup: 10
actions:
  - http:
      title: Ping Google
      method: GET
      # client: fasthttp
      url: https://www.google.com

@eriklupander
Copy link
Owner

Thanks, awesome work. Did you get the performance issue sorted out?

@missedone
Copy link
Collaborator Author

nope, even i use the lock-free approach for creating request/response object in commit: da3a8d5

i guess there still other lock/sync operation in fasthttp internal, will see.

@missedone
Copy link
Collaborator Author

i'd like to pend this since still fasthttp not perform as fast as net/http.

@eriklupander
Copy link
Owner

Ok, good work nevertheless.

@jpallari
Copy link

jpallari commented Jun 28, 2017

Interesting work! :-) I wonder if sharing a single fasthttp client across multiple go-routines would help.

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

No branches or pull requests

3 participants