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

-q or --burst-rate and --burst-delay do not send correct number of requests? #577

Open
pvardanis opened this issue Sep 12, 2024 · 6 comments

Comments

@pvardanis
Copy link

pvardanis commented Sep 12, 2024

I'm doing a load testing with oha and want to achieve 5 qps. I've tried both using:

oha -z 1m --burst-delay 1s --burst-rate 5 --latency-correction --disable-keepalive --wait-ongoing-requests-after-deadline

and

oha -z 1m -q 5 --latency-correction --disable-keepalive --wait-ongoing-requests-after-deadline

and only get around ~55 responses, all with 200. I'm I doing something wrong? Tried to increase -c as well and the number of requests did increase (without achieving what I want) but seems if I push too high my Mac crashes. FWIW a response might take anywhere from 20-180s.

@hatoo
Copy link
Owner

hatoo commented Sep 12, 2024

I want to see a latency histogram.
Could you add a full example of a run of -q version? (command and full output)

@hatoo
Copy link
Owner

hatoo commented Sep 12, 2024

--wait-ongoing-requests-after-deadline doesn't ensure it will do Qps * seconds requests.
It waits for requests that are started but not ended when the deadline is reached.
So it is normal that oha has done less than 60 * 5 requests when the target server is slow.

@pvardanis
Copy link
Author

pvardanis commented Sep 12, 2024

Sure, here's the command using -q:

oha -z 1m -q 1 --latency-correction --disable-keepalive --wait-ongoing-requests-after-deadline -m POST -H "Content-Type: application/json; format=pandas-records" \
-H "Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJza25IaEpqZEU2WHk1SjdBc0FKUmdUelVTQXJpSGY3RWRiNXk4d2d5a05zIn0.eyJleHAiOjE3MjYxNTg5MjksImlhdCI6MTcyNjE1NTMyOSwianRpIjoiNzgwOGM4YTUtMTcwYy00Y2I5LWE4NWMtOTc1ZDMwMTBiNGY0IiwiaXNzIjoiaHR0cHM6Ly9jdXJseS1wbHVtLTM4Njgud2FsbGFyb28uZGV2L2F1dGgvcmVhbG1zL21hc3RlciIsImF1ZCI6WyJtYXN0ZXItcmVhbG0iLCJhY2NvdW50Il0sInN1YiI6IjdmZWVlOTNhLWFiODgtNGQ1MC1iZGQ3LTQ2ZjA1YWNjNTk4NCIsInR5cCI6IkJlYXJlciIsImF6cCI6InNkay1jbGllbnQiLCJzZXNzaW9uX3N0YXRlIjoiNjZkOTZjMDQtNTNjZS00ZDE1LWFjZTMtODllMWM3NDNiNDAzIiwiYWNyIjoiMSIsInJlYWxtX2FjY2VzcyI6eyJyb2xlcyI6WyJkZWZhdWx0LXJvbGVzLW1hc3RlciIsIm9mZmxpbmVfYWNjZXNzIiwidW1hX2F1dGhvcml6YXRpb24iXX0sInJlc291cmNlX2FjY2VzcyI6eyJtYXN0ZXItcmVhbG0iOnsicm9sZXMiOlsidmlldy1yZWFsbSIsIm1hbmFnZS11c2VycyIsInZpZXctdXNlcnMiLCJxdWVyeS1ncm91cHMiLCJxdWVyeS11c2VycyJdfSwiYWNjb3VudCI6eyJyb2xlcyI6WyJtYW5hZ2UtYWNjb3VudCIsIm1hbmFnZS1hY2NvdW50LWxpbmtzIiwidmlldy1wcm9maWxlIl19fSwic2NvcGUiOiJvcGVuaWQgZW1haWwgcHJvZmlsZSIsInNpZCI6IjY2ZDk2YzA0LTUzY2UtNGQxNS1hY2UzLTg5ZTFjNzQzYjQwMyIsImVtYWlsX3ZlcmlmaWVkIjp0cnVlLCJodHRwczovL2hhc3VyYS5pby9qd3QvY2xhaW1zIjp7IngtaGFzdXJhLXVzZXItaWQiOiI3ZmVlZTkzYS1hYjg4LTRkNTAtYmRkNy00NmYwNWFjYzU5ODQiLCJ4LWhhc3VyYS11c2VyLWVtYWlsIjoicGFuYWdpb3Rpcy52YXJkYW5pc0B3YWxsYXJvby5haSIsIngtaGFzdXJhLWRlZmF1bHQtcm9sZSI6InVzZXIiLCJ4LWhhc3VyYS1hbGxvd2VkLXJvbGVzIjpbInVzZXIiXSwieC1oYXN1cmEtdXNlci1ncm91cHMiOiJ7fSJ9LCJwcmVmZXJyZWRfdXNlcm5hbWUiOiJwYW5hZ2lvdGlzLnZhcmRhbmlzQHdhbGxhcm9vLmFpIiwiZW1haWwiOiJwYW5hZ2lvdGlzLnZhcmRhbmlzQHdhbGxhcm9vLmFpIn0.SQ6eWH3rqn_5AeZWXMZU9x-JFr7nFwSxQxYebZkPx9pjfqKFHp2Thz2qRIv-J1KQSIJemg8iAH2NfszYT_WpP_En2GHST38JSOyl5QqA1r0GIH6YmA88anP79tGye4tQlbrCnllwef3NxGlkrq-jM_LVfFxFiOuyDwSkLMtiwz7Aon8Y3jBFrPGq2s07cP7aJri9DXg-31CEUjFUUHHoueChjTrZ1mDyNcZENHuMgKp0q7EELJ_PxAmEOx4dEnUbOZrC3XwxywYll4EfSaeBtDUX0pROZQlx-DTorGEPv2gbBnzhysc2PK685U3ZfsUfEwaWmycS0R-9b_dSeFgRyw" -d '<some-data>' <some-url>

and the output:

Summary:
  Success rate:	100.00%
  Total:	265.5045 secs
  Slowest:	213.5019 secs
  Fastest:	10.6163 secs
  Average:	119.1283 secs
  Requests/sec:	0.1996

  Total data:	470.35 KiB
  Size/request:	8.87 KiB
  Size/sec:	1.77 KiB

Response time histogram:
   10.616 [1]  |■■
   30.905 [1]  |■■
   51.193 [0]  |
   71.482 [8]  |■■■■■■■■■■■■■■■■■■
   91.771 [5]  |■■■■■■■■■■■
  112.059 [8]  |■■■■■■■■■■■■■■■■■■
  132.348 [8]  |■■■■■■■■■■■■■■■■■■
  152.636 [5]  |■■■■■■■■■■■
  172.925 [14] |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
  193.213 [2]  |■■■■
  213.502 [1]  |■■

Response time distribution:
  10.00% in 61.2655 secs
  25.00% in 81.2649 secs
  50.00% in 116.4977 secs
  75.00% in 159.9910 secs
  90.00% in 168.9835 secs
  95.00% in 173.2801 secs
  99.00% in 213.5019 secs
  99.90% in 213.5019 secs
  99.99% in 213.5019 secs


Details (average, fastest, slowest):
  DNS+dialup:	0.4218 secs, 0.3972 secs, 0.4479 secs
  DNS-lookup:	0.0006 secs, 0.0000 secs, 0.0235 secs

Status code distribution:
  [200] 53 responses

by deadline you mean -z? Can I configure it somehow to wait for unfinished requests after the deadline? Setting -n to 60*5 maybe and not configuring -z?

@hatoo
Copy link
Owner

hatoo commented Sep 12, 2024

Thank you, it looks that oha has done only 53 requests because the server isn't fast enough.

by deadline you mean -z? Can I configure it somehow to wait for unfinished requests after the deadline? Setting -n to 60*5 maybe and not configuring -z?

Yes, you can make 300 requests by -n 300 and not setting -z

@pvardanis
Copy link
Author

Ok, just to clarify, will the -q 5 still apply?

@hatoo
Copy link
Owner

hatoo commented Sep 12, 2024

Yes

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