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

Options to show the response code pages #276

Open
ghost opened this issue Mar 24, 2022 · 8 comments
Open

Options to show the response code pages #276

ghost opened this issue Mar 24, 2022 · 8 comments

Comments

@ghost
Copy link

ghost commented Mar 24, 2022

Not an issue (maybe)...
When I run the awesome Hey against one of my sites, it lists a ton of 503 response codes which makes no sense as I cannot see these with any other tools including muffet.

Is there a hidden flag to show all the responses and links that Hey is checking? Makes sense if it's reporting something that we can see it too.

thanks, amazing tool btw!

@FrenchBen
Copy link

Chances are the default content-type is what's causing these 503 - Try adding -T "text/plain" to your requests, and see if that helps.

@ghost
Copy link
Author

ghost commented Mar 25, 2022

Thanks! Just tried, sadly the same output. Running:

hey -T "text/plain" https://DOMAIN.com/

gave me:

Status code distribution:
  [200]	12 responses
  [503]	188 responses

@ghost
Copy link
Author

ghost commented Mar 25, 2022

Interesting... tried with different sites & hosting Co's, this is only happening on sites hosted by Brizy.cloud which we use. They use AWS on the back. Here's a test page if it helps:

test brizy.cloud

full URL for clarity:
https://pear10259858.brizy.site/

@FrenchBen
Copy link

Saw something similar, and working on a -debug flag to dump the request responses to a file. Perhaps it will help debug this. The provided endpoint will help me see the value in it. Thanks for sharing!

@FrenchBen
Copy link

FrenchBen commented Apr 5, 2022

Re-ran against your endpoint, with a -debug, which dumps all requests to a log file. Results were similar to what you saw:

./bin/hey -debug -n 8 -c 2 https://pear10259858.brizy.site

Summary:
  Total:        0.6419 secs
  Slowest:      0.4072 secs
  Fastest:      0.0715 secs
  Average:      0.1603 secs
  Requests/sec: 12.4637
  
  Total data:   412 bytes
  Size/request: 51 bytes

Response time histogram:
  0.071 [1]     |■■■■■■■■
  0.105 [5]     |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
  0.139 [0]     |
  0.172 [0]     |
  0.206 [0]     |
  0.239 [0]     |
  0.273 [0]     |
  0.307 [0]     |
  0.340 [0]     |
  0.374 [0]     |
  0.407 [2]     |■■■■■■■■■■■■■■■■


Latency distribution:
  10% in 0.0734 secs
  25% in 0.0796 secs
  50% in 0.0811 secs
  75% in 0.4061 secs
  0% in 0.0000 secs
  0% in 0.0000 secs
  0% in 0.0000 secs

Details (average, fastest, slowest):
  DNS+dialup:   0.0594 secs, 0.0000 secs, 0.2379 secs
  DNS-lookup:   0.0010 secs, 0.0000 secs, 0.0040 secs
  req write:    0.0003 secs, 0.0000 secs, 0.0008 secs
  resp wait:    0.0951 secs, 0.0713 secs, 0.1574 secs
  resp read:    0.0053 secs, 0.0002 secs, 0.0163 secs

Status code distribution:
  [200] 6 responses
  [503] 2 responses

Sample from the logs:

{"level":"debug","msg":"HTTP/1.1 503 Service Temporarily Unavailable\r\nContent-Length: 206\r\nConnection: keep-alive\r\nContent-Type: text/html\r\nDate: Tue, 05 Apr 2022 16:31:06 GMT\r\nServer: nginx\r\n\r\n\u003chtml\u003e\r\n\u003chead\u003e\u003ctitle\u003e503 Service Temporarily Unavailable\u003c/title\u003e\u003c/head\u003e\r\n\u003cbody bgcolor=\"white\"\u003e\r\n\u003ccenter\u003e\u003ch1\u003e503 Service Temporarily Unavailable\u003c/h1\u003e\u003c/center\u003e\r\n\u003chr\u003e\u003ccenter\u003enginx\u003c/center\u003e\r\n\u003c/body\u003e\r\n\u003c/html\u003e\r\n","time":"2022-04-05T09:31:06-07:00"}

The above makes me assume that the service limits the number of requests that it can process given a certain timespan, and will return 503 when that is exhausted. (prevents hammering the service)

The current implementation dumps both 200 responses and 503 responses in its current form, should it only be non-200 codes that get dumped? Following this I can make a PR here if it helps.

@ghost
Copy link
Author

ghost commented Apr 6, 2022

Your thinking makes sense (service hammering). If it's any help, Brizy use AWS for their tech stack but, I've not seen this on any other hosted websites even with AWS. Your PR would be a great idea to capture these quirks.

Thanks!

@hrchu
Copy link

hrchu commented Jul 8, 2022

@FrenchBen which version has the -debug option?

@FrenchBen
Copy link

@hrchu this is my fork of Hey :)

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

2 participants